When attempting to register a new device via the /device/register endpoint the error message "API key must be used for registering" is returned.
This is caused by using a session token rather than an API key.
Related
I am trying to run a simple report on GA4 by using Google Analytics Data API Python client with a regular user credentials:
request = RunReportRequest(
property=f"properties/11111",
dimensions=[Dimension(name=f['name']) for f in report_definition['dimensions']],
metrics=[Metric(name=f['expression']) for f in report_definition['metrics']],
date_ranges=[DateRange(start_date=date, end_date=date)],
)
response = client.run_report(request)
And the client is BetaAnalyticsDataClient as also mentioned in the documentation:
credentials = Credentials(
token=None,
refresh_token=config['refresh_token'],
client_id=config['client_id'],
client_secret=config['client_secret'],
token_uri="https://accounts.google.com/o/oauth2/token",
scopes=["https://www.googleapis.com/auth/analytics.readonly"]
)
client = BetaAnalyticsDataClient(credentials=credentials)
It is not a Service Account so I am using google.oauth2.credentials.Credentials class as same in other Google APIs.
However, this operation is throwing an exception during the run_report function:
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
status = StatusCode.UNAVAILABLE
details = "Getting metadata from plugin failed with error: ('invalid_grant: Bad Request', {'error': 'invalid_grant', 'error_description': 'Bad Request'})"
debug_error_string = "UNKNOWN:Error received from peer analyticsdata.googleapis.com:443 {created_time:"2023-01-14T14:12:10.907813+03:00", grpc_status:14, grpc_message:"Getting metadata from plugin failed with error: (\'invalid_grant: Bad Request\', {\'error\': \'invalid_grant\', \'error_description\': \'Bad Request\'})"}"
>
And when I try to use my access token in the credentials:
credentials = Credentials(
token=config["token"],
refresh_token=config['refresh_token'],
client_id=config['client_id'],
client_secret=config['client_secret'],
token_uri="https://accounts.google.com/o/oauth2/token",
scopes=["https://www.googleapis.com/auth/analytics.readonly"]
)
This time I am getting following error:
google.api_core.exceptions.Unauthenticated: 401 Request had invalid authentication credentials. Expected OAuth 2 access token, login cookie or other valid authentication credential. See https://developers.google.com/identity/sign-in/web/devconsole-project.
I am sure that my credentials is correct since I am using same account in my other repos.
Also, note that, I tried same operation with a service account and it does not give any error. However, for this purpose, I need to use a regular developer account since the OAuth flow is on a frontend project.
What are the suggestions on that issue? Is it possible to use a developer account in here and if yes, how?
I was able to fix the issue. The app just needs a sign-out sign-in (or refreshing the access token).
Corda Token SDK https://github.com/corda/token-sdk.
By default, the fungible token can be issued many times, to many accounts.
I do not know to limit that fungible token is issued once and sent to a specific account
(after that token will not be issued any more)
Does anyone have an idea?
To implement that, you'd have to do the following:
Create your own EvolvableTokenType.
Your evolvable token type will have 2 custom attributes (that can be changed over time, thus why we chose evolvable over fixed token type):
issued of type boolean
issueAccount of type AbstractParty
Create a contract that validates your evolvable token type (it should extend EvolvableTokenContract):
Implement additionalCreateChecks: You can keep it empty.
Implement additionalUpdateChecks: Here you can validate that you can only update the value of issued to true, you cannot update it to false (this will allow issuing more of your token type which we don't want).
Create a flow that creates your evolvable token type, it sets the issueAccount to the value that you pass as input parameter and sets issued to false.
Now you can create your evolvable token token type and use it to issue tokens of that type.
Create a flow that issues tokens of your token type:
It will fetch the latest version of your evolvable token type.
If the value of issued is true, throw a FlowException that this token has already been issued and you cannot issue it again.
Use the returned state to get the issueAccount value.
Call the IssueToken flow to issue your token type to issueAccount. Of course you need to generate a new key for the account using RequestKeyForAccount and wrap the returned PublicKey in an instance of AnonymousParty.
Now the most important part (your requirement): Call UpdateEvolvableToken flow to update your evolvable token type and set issued to true. This way if someone calls your issue tokens flow again, it will throw an exception because your token type has been issued.
The Kotlin template (token branch) has a high level example of EvolvableTokenType:
Type: https://github.com/corda/cordapp-template-kotlin/blob/token-template/contracts/src/main/kotlin/com/template/states/ExampleEvolvableTokenType.kt
Contract: https://github.com/corda/cordapp-template-kotlin/blob/token-template/contracts/src/main/kotlin/com/template/ExampleEvolvableTokenTypeContract.kt
Flow (it has 2 flows, create token type and issue it): https://github.com/corda/cordapp-template-kotlin/blob/token-template/workflows/src/main/kotlin/com/template/flows/ExampleFlowWithEvolvableToken.kt
Also the Tokens SDK has an example that uses EvolvableTokenType where the House token has an attribute that can change (valuation):
https://github.com/corda/token-sdk/blob/master/docs/DvPTutorial.md#define-your-states-and-contracts
I am trying to verify a HS256 JWT Token generated with locally ran KeyCloak Authentication Provider on https://jwt.io.
The KeyCloack instance is running on my local machine inside a docker container. I have applied almost the same steps as described in this answer (which on contrary applies the RS algorithm instead, and works as described): https://stackoverflow.com/a/55002225/1534753
My validation procedure is very simple:
1.) Request the token (with Postman) from my local docker KeyCloak instance with:
POST requesting http://localhost:8080/auth/realms/dev/protocol/openid-connect/token
2.) Copy the token contents inside the jwt.io's "Encoded" section
3.) I verify that the header and payload are as expected and correct
4.) I copy the client secret from my KeyCloak instance admin dashboard, you can see the reference on the image below:
5.) I paste the secret into the "VERIFY SIGNATURE" section on jwt.io and the "Encoded" token section changes, hence resulting with an invalid signature and a invalid (i.e. different) token.
My core question is what am I missing here? Why does the token change when I apply the expected secret!? Am I applying the right secret, the one from the client? If I understand JWT infrastructre and standard correctly then It should stay the same if the secret (with the expected algorithm applied) is valid. My reasoning is that something with JWT creation on KeyCloak is specific. I have not touched the HS256 algorithm provider on KeyCloak, everything is used as default with the docker installation guide on using KeyCloak. The settings related to the token and algorithm are setup to use HS256, and the algorithm is specified as expected in the JWT's header section correctly which can be verified after the encoded token is pasted into the jwt.io's page.
I need this to work as I am trying to apply the same JWT validation process inside a .NET Core web API application. I have encountered this whole issue in there, i.e. inside the System.IdentityModel.Tokens.JWT and the JwtSecurityTokenHandle.ValidateSignature method which results with an invalid signature and finally resulting in an exception.
On side note, I am accessing the token with Postman and its Authorize feature the configuration can be seen on the image below:
One more side note is I have a user "John" which belongs to my "Demo" realm. I use him to request an access token from KeyCloak.
To get the secret used for signing/verifying HS256 tokens, try using the following SQL:
SELECT value FROM component_config CC INNER JOIN component C ON(CC.component_id = C.id) WHERE C.realm_id = '<realm-id-here>' and provider_id = 'hmac-generated' AND CC.name = 'secret';
If you use the resulting secret to verify the tokens, the signature should match. I’m not sure if this secret is available through the UI, probably not.
Source: https://keycloak.discourse.group/t/invalid-signature-with-hs256-token/3228/3
you can try using Keycloak Gatekeeper.
If you want to verify that token in that way you need to change the Client Authenticator to "Signed JWT with client secret", otherwise you can use this "Gatekeeper" option. Here you can read more about it.
When I attempt to derive an APIkey from a user account in Workfront using the methods detailed in https://developers.workfront.com/api-docs/#API_key I only get a blank response. Whilst most users in this domain auth using SAML the user in question has been set up as a API account and SAML is disabled.
The URL used is:
/attask/api-internal/user?action=getApiKey&username=yyyyy#xxxxx&password=xxxxxxxx&method=put (xxx and yyy masking actual text)
... and I receive the following result. I get the same result in both prod and sandbox
{
data: {
result: ""
}
}
If I use an invalid user/password pair I receive the following result:
{
error: {
class: "com.attask.common.AuthenticationException",
message: "That username/password combination wasn't quite right.
Make sure your caps lock isn't on and try again."
}
}
If use the user/password method to auth (https://developers.workfront.com/api-docs/#Authentication) this works and I receive the full session information.
If you are getting a blank response then you do not have a API key to get. You can either generate on in the UI by opening setup > system > customer info or through the API
/attask/api/v5.0/user?action=generateApiKey&username=yyyyy#xxxxx&password=xxxxxxxx&method=put
I need to access a private data set in socrata using SODA API. Suppose below link is the data set
https://data.cityofchicago.org/resource/xxxx-xxx.json
I get the following error when try this.
"error" : true,
"message" : "You must be logged in to access this resource"
I have valid credentials to access the data set. But how can I pass it through SODA API calls?
I tried the below code but it doesn't work.
https://data.cityofchicago.org/resource/xxxx-xxx.json?$username='myname'&$password='pwd#123'
You'll need to use either HTTP Basic or OAuth 2.0 to authenticate. We have details on how to do that on the developer portal.
Make sure you also provide an application token, as detailed in those docs.
You need to pass Secret-Token and AppToken with the query string.
How to Get secret Token
Log in to your portal and select "Create new Application"
Enter https://data.cityofchicago.org/resource/xxxx-xxx.json in the "website" field.
Save it.
Go to "Manage" and get your AppToken and SecretToken from under "Manage".
Now, pass the app token and secret token in the URL according to socrata developer document syntax:
https://sandbox.socrata.com/oauth/access_token
?client_id=YOUR_AUTH_TOKEN
&client_secret=YOUR_SECRET_TOKEN
&grant_type=authorization_code
&redirect_uri=YOUR_REDIRECT_URI
&code=CODE
I am also looking for an answer for the same question. After passing the app token I can access public DB but can not access Private DB.