I want to GET the user details based on email. So I am trying to use this Okta API https://developer.okta.com/docs/reference/api/users/#get-user-with-login . I am able to use it via Postman and curl. But via google-apps-script I get errorCode":"E0000005","errorSummary":"Invalid session". I am not sure on how I can clear the session or cookie in google-apps-script so that it starts working. I am certain that I am using the proper token and end point.
The "Invalid session" error usually occurs when the API token you are using doesn't have sufficient permissions. Check to see if you are using the same API key/token in postman as in the script.
Related
I am facing one problem that i am unable to login to the liferay website using JMeter.
The problem i know already but don't know how to hanmdle it.
I get to know that "p_auth" token is requried to access the sub pages, but here i am facing an issue in which i don't even able to acccess the login page itself if run the script second time.
My concerns:
how to check "p_auth" token parameter for login page (i.e without login)
Please help me to solve the problem.
Note: i tried to extract the "p_auth" token , but i am unable to see any "p_auth" token for login page itself(i.e without login.. just a login page(get api))
Your test plan need to look like:
Open Login Page - HTTP GET request
Extract p_auth dynamic parameter value using a suitable JMeter Post-Processor
Perform the login - HTTP POST request where you need to provide your credentials and the p_auth token value from the previous request
You won't be able to "see" the token in the page, it's hidden in the page source so you will need to use browser developer tools or JMeter's View Results Tree listener in order to "see" the token value.
Also don't forget to add HTTP Cookie Manager to your test plan as missing CSRF token is not the only thing which can stop you from logging in.
I'm trying to access info within GitHub's API from a NiFi Process. Essentially, I'm using GenerateFlowFile to set the target URL and the Authorization header for the token. I then pass it to the InvokeHTTP and every time it gets a 401 error saying it needs to be authenticated, despite providing my personal token (the one I use when programming locally and with Terminal). Any tips on how I can get this working? I can provide more detail if needed
I'm not sure which endpoint you're trying to access in the GitHub API, but it appears you are using an endpoint from GitHub Enterprise 2.22 from the error message.
The docs for authentication show you should prefix the token with token i.e:
Authorization: token OAUTH-TOKEN
In your specific case, this means you should set the Authorization header to token ${github_token}.
I am using Laravel as my backend together with Sanctum which generates personal access token for mobile users. For my mobile application I am using flutter.
To authenticate users they login with their username/password and get a personal access token in return. This works but requires a user to login every time they open the application again so I did what most tutorials suggest which is saving the token on the mobile device using shared preferences/secure storage.
Now comes the question how do you invalidate a user when you remove their token from the backend? On initial login it appears everything is still fine because like in most tutorial I check for the existence of a token. After that whenever I want to make a request which uses the token I obviously run into problems because it not longer exists on the backend.
Most tutorials/guide suggest saving the token and using that a reference to see if the user is logged in or not but this seems flawed because it gives the false impression you actually have a valid token.
My guess is this can be solved by always performing a heartbeat/ping action to check if the current token is valid and if not send them to the login screen instead of simply checking for the existence of the token.
Thoughts on this?
I can suggest a hack or trick here in every launch of the app you can send a request to an API to check if the user's token is valid or not and if it is valid then you can continue the app otherwise force the user to login and generate new token this way your app will be secure via server / API.
For this, you can store the user's secret token in the database and check it via HTTP API call and send a response from the API accordingly and check the response in app and do the next operation according to the response you get.
I don't know if this is a great way of doing this job but it is a kind of hack/trick to achieve what is needed.
Thanks
I'm trying to upload and publish my Chrome Extension using Chrome Web Store API in Azure DevOps. I've been referencing the official Google guide but the problem is that it looks like it's outdated now. I'm failing at the step
To create the client ID and client secret, click on Create New Client ID, select Installed Application, and Other under Installed application type.
When I do this, I don't see option for "Other" in Application Type dropdown.
I've tried the following:
Choosing Web Application as Application Type
With this I'm not able to get an access code with this link:
https://accounts.google.com/o/oauth2/auth?response_type=code&scope=https://www.googleapis.com/auth/chromewebstore&client_id=$CLIENT_ID&redirect_uri=urn:ietf:wg:oauth:2.0:oob
it's resulting in "Error 400: redirect_uri_mismatch". If I add an authorized redirect URI in my Client ID settings, like 'localhost', and replace 'urn:ietf:wg:oauth:2.0:oob' in URL above with it, I'm able to invoke authorization process and get the code from URL. But when I try to make a curl request to https://accounts.google.com/o/oauth2/token to get the refresh token I don't receive a refresh token, I only get this:
{
"access_token": "",
"expires_in": 3599,
"scope": "https://www.googleapis.com/auth/chromewebstore",
"token_type": "Bearer"
}
Choosing Chrome App as Application Type
Pretty much the same happens here as in previous attempt, except I don't have to substitute the redirect URI in request for access code, but I also don't have Client Secret for this application type, so I just omit it. Anyways, it results in the same response that doesn't have refresh token.
When I enable Chrome Web Store API in dev console and try to create new credentials, it suggests to create API key instead of Cliend ID. But it doesn't look like this API can actually work with this key, I've tried sending it as query param, as a header, and I always get 401 result with "Login Required" message. But when I try to send a request with (invalid) token in a header I get meaningful response (smth like Invalid Credentials).
Apparently I do need to have access token to work with Chrome Web Store API but without refresh token I need to manually authorize my permissions and that's not acceptable because I need to use in my CI/CD pipeline. It looks like Google removed the option to just generate this info for such application types.
So, the question is, how can I get the refresh token to actually be able to continuously deploy the chrome extension?
Ok, so the trick here was to add two params to the request that you use to get the access code (not token):
&access_type=offline&approval_prompt=force
And so the link should be:
https://accounts.google.com/o/oauth2/auth?response_type=code&scope=https://www.googleapis.com/auth/chromewebstore&client_id=$CLIENT_ID&redirect_uri=urn:ietf:wg:oauth:2.0:oob&access_type=offline&approval_prompt=force
And Google should do better job in updating their docs.
I'm trying to implement a oAuth login flow in a bash script.
The request I need to send to my API is:
curl -X GET 'http://account.lab.fiware.org/oauth2/authorize?response_type=token&client_id=my_client_id&redirect_uri=my_redirect_uri&state=testing'
I keep getting a 301 Moved Permanently Apache message referencing to the same address..
When trying the same url from my browser - it does work.
Is there a way that I can copy the browser behaviour with curl?
So, once the above request has been made I will be able to see the redirect location in order to get the token from?
that OAuth2 grant is thought to be used from a web browser. You have other grant types that can be user from server side. Take a look to:
http://fiware-idm.readthedocs.org/en/latest/oauth2.html#oauth2-authentication
BR