In Magento 2, customer tokens expire after an hour and the user is forced to login again. Is there a way to refresh the token?
The docomentation of mangeto does not specify such a mechanism. I am developing a mobile application and I want the customer to be logged as longer as possilbe.
You could increase cookie lifetime which can be found in Admin Backoffice at Stores > Configuration > General > Web > Default Cookie Settings section
Make sure you switch the scope from Default Config to either Website or Store View if you have multiple stores.
See Magento docs for more info.
Edit:
I just realised that you are talking about OAuth tokens and not sessions. If that's the case, you still need to edit one value in config, which can be found at Stores > Configuration > Services > OAuth > Access Token Expiration section
Docs.
Related
I want to use the gmail api to update myself about the status of a programm I'm running locally 24/7. Basicly once a day it should send me a status report per email from the emailaccount I created just for this case to the same account.
I've got a project set up, the api enabled, got my credentials and created a token.json file. I managed to have it send me emails yada yada yada.
I concentrated on the further development of the programm for some time and then wanted to jump back to this to test out another feature where I wanted to implement a ping me feature. I'd send myself an email asking for a ping back just to check if my program is still running.
While doing that I noticed that my token expired. I tried reading into what I can do about that. Ideally I'd like to have the program just run autonomously. I read for my case that a service account would be ideal but after setting that all up and 2 hours later after a lot of errors I read that interacting with the gmail api with a service account is only open to workspace users since I can't delegate domain-wide authority without one.
So after some further reading I read that next to the access token I created I can refresh that token with refresh tokens. for that I was trying the request function noted in the quickstart tutorial:
if os.path.exists('token.json'):
creds = Credentials.from_authorized_user_file('token.json', SCOPES)
if not creds or not creds.valid:
if creds and creds.expired and creds.refresh_token:
creds.refresh(Request())
now running creds.refresh(Request())
I get this error:
google.auth.exceptions.RefreshError: ('invalid_grant: Token has been expired or revoked.', {'error': 'invalid_grant', 'error_description': 'Token has been expired or revoked.'})
Upon further reading here I read that refesh tokens are only available to projects whose status is set to in progress and not in testing. Projects set to testing are required to have the user manually log in at least once a week which I don't want.
Now for me verifying my project doesn't make sense since I won't have any other users using my access to the gmail api and frankly I wouldn't want that either.
What are my options here to have the script running continuously without having to manually sign in once a week? Considering also that I will be at all times the only user.
Thank you,
Florens
Your still have a few options. For one, you could get a Google Workspace account. The lowest tier would set you back around $6 per user per month. This would allow you to publish the app as internal-only and you don't need to go through the verification process, but you can only use the app with the Workspace account. You can still send emails out to any addresses, though.
If you don't want to pay, you can still set your app to Published status and you do not necessarily have to go through the verification. There are some limitations, such as the app warning that shows up when signing in and a user cap of 100 users, but since you know that the app is safe and you don't need more users you can just ignore this, Google says so in their own documentation:
What app types are not applicable for verification?
Personal Use: The app is not shared with anyone else or will be used by fewer than 100 users. Hence, you can continue using the app by bypassing the unverified app warning during sign-in.
As you already know, the refresh token expires in 7 days only when the app status is set to "testing", so as long as you have it set as "In production" and ignore the unverified app warnings, you should be able to have a normal refresh token that you can use without needing to sign in every 7 days.
Just keep in mind that other users could have access to the app but if you're careful to keep your OAuth credentials to yourself that should not be an issue.
Sources:
Unverified apps
OAuth API verification FAQs
OAuth overview
I'm using adal.js on my react app (using react-adal wrapper). I configured my app to work with my ADFS 2016 server (on premise), and the authentication process works fine, but after the ADFS SSO cookie expired, when the client sends the renew token request (in an hidden iframe), the browser shows in the console the following error: refuse to display 'https://myadfs/adfs/ls/SAMLRequest=...' in a new frame because it set 'X-frame-options' to deny.
In order to reauthenticate, the user needs to refresh the page (F5).
Is there any solution / workaround to this problem?
ADFS <= 2016 does not allow iFrame based logins for any interactive authentication for security reasons. This would have worked if the user did not need to perform an interactive sign-in (either SSO cookie or WIA).
The right pattern (since you are on 2016) is to use OIDC flows to log into the application and use the refresh token to get new access tokens.
Even here you need to handle the refresh token expired case where you will need to store your app context locally (cookie or local cache) and enable a full redirect to ADFS.
ADFS 2019 now has the option where an admin can configure options for which host(s) they allow iFrames by controlling the headers.
Thanks //Sam (Twitter: #MrADFS)
Like I explained in this similar question, the commandlet "Set-AdfsResponseHeaders" is also supported on ADFS 2016 since a recent MS update (about May 2019) :
Set-AdfsResponseHeaders -RemoveHeaders "X-Frame-Options"
Howeber, I agree with SamuelD MSFT on the fact that it's not a good practice any more to use iFrame integration nowadays.
I am developing an Angular2 app which uses auth0 for authentication. I used the auth0 lock widget to authenticate users.
Now, I want to use auth0-js instead of the lock widget for authentication. I followed this guide to add auth0-js to the app.
After adding auth-js, when a new user tries to log in to the app, Auth0 displays following consent screen to the user.
I want the users to be able to directly access my app, without needing to accept a consent screen. The consent question asked in this dialog can be confusing to users since it mentions about tenants.
When I searched for a solution, the solution mentioned in various places was to make the client a first party client. But, I cannot find any place in the management console to make the client a first party client.
How can I disable this consent screen?
Following is the auth-js config I used in the app.
auth0 = new auth0.WebAuth({
clientID: 'my_client_id',
domain: 'my_domain.auth0.com',
responseType: 'token id_token',
audience: 'https://my_domain.auth0.com/userinfo',
redirectUri: window.location.origin + '/auth_loading',
scope: 'openid'
});
In Auth0 Dashboard, under APIs -> Auth0 Management API -> Settings (tab)
If you are using a specific audience for a Resource API you have defined yourself in the Dashboard, then there is a similar Allow Skipping User Consent toggle for that particuar API. Use that. audience specifies the target API for your access token. If you don't want to call a specific API, keep it set to https://my_domain.auth0.com/userinfo
Re. question about First Party. If you created your client in the Auth0 Dashboard, then it is Firsty Party by default. Only first-party clients can skip the consent dialog, assuming the resource server they are trying to access on behalf of the user has the "Allow Skipping User Consent" option enabled. The Auth0 Dashboard does not offer a flag for this, but if you use the Auth0 Management API v2 Get Clients endpoint, then you will see the flag (boolean) value listed for your client eg.
"is_first_party": true
See https://auth0.com/docs/api/management/v2#!/Clients/get_clients for details.
Finally, please note the following: https://auth0.com/docs/api-auth/user-consent#skipping-consent-for-first-party-clients - in particular note that consent cannot be skipped on localhost. As per the docs (link above), During development, you can work around this by modifying your /etc/hosts file (which is supported on Windows as well as Unix-based OS's) to add an entry such as the following:
127.0.0.1 myapp.dev
Currently Google Assitant includes an easy way to request non-identifiable information about the user and a detailed flow to authenticate the user on a third party service through OAuth2. What about if all I need is have the user authenticate on Google itself? I tried filling in the account linking flow using Google OAuth2 information, but that seems not to work. If that last thing is supposed to work fluently than that would be enough of an answer.
Context: Users already authenticate only with Google on a related webpage. All I need is to link this already authenticated account with the less-authenticated account on Google Assistant.
Update, 25 Oct 2018:
As of 13 September 2018, there is now a much simpler way to access the user's account if your project uses Google Sign-In. Google Sign-In for Assistant will give you an ID Token with information about the user, including their Google ID, with their permission. This permission can be granted just using voice and is fairly streamlined.
You can combine this with a web- or app-based Google Sign-In to get their permission to access OAuth scopes if you need to access Google's APIs.
Update, 25 Oct 2017:
As of around 4 Oct or 7 Oct, Google has updated their policy (again) to restore language restricting OAuth endpoints that are valid. The terms now include
When implementing account linking using OAuth, you must own your OAuth endpoint
and it appears (from the comments below) that they now check for the Google endpoints to prevent this method from working.
At this point, the only thing you can do is setup your own OAuth2 server.
Original Post:
Broadly speaking, the auth tasks you need to do are in four parts:
Configure your project (in the cloud console) so that the Calendar API is enabled and that the OAuth2 client is correctly configured.
Configure the Action for account linking in the action console.
Configure the Actions on Google Integration for your API.AI Agent to indicate that sign-in is required.
When API.AI calls your webhook to fulfill an Intent, it will include an auth token as part of the JSON. You can use this token to make calls to the Google APIs you need.
Configure Cloud Project
You need to configure your cloud project so that it has access to the Google APIs you need and setup the OAuth2 Client ID, Secret, and Redirect URI.
Go to https://console.cloud.google.com/apis/dashboard and make sure you have the project you're working with selected. Then make sure you have the APIs you need enabled.
Select the "Credentials" menu on the left. You should see something like this:
Select "Create credentials" and then "OAuth client ID"
Select that this is for a "Web application" (it is... kinda...)
Enter a name. In the screen shot below, I used "Action client" so I remember that this is actually for Actions on Google.
In the "Authorized Redirect URIs" section, you need to include a URI of the form https://oauth-redirect.googleusercontent.com/r/your-project-id replacing the "your-project-id" part with... your project ID in the Cloud Console. At this point, the screen should look something like this:
Click the "Create" button and you'll get a screen with your Client ID and Secret. You can get a copy of these now, but you can also get them later.
Click on "Ok" and you'll be taken back to the "Credentials" screen with the new Client ID added. You can click the pencil icon if you ever need to get the ID and Secret again (or reset the secret if it has been compromised).
Configure the Action Console
Once we have OAuth setup for the project, we need to tell Actions that this is what we'll be using to authenticate and authorize the user.
Go to https://console.actions.google.com/ and select the project you'll be working with.
In the Overview, make your way through any configuration necessary until you can get to Step 4, "Account Linking". This may require you to set names and icons - you can go back later if needed to correct these.
Select the Grant Type of "Authorization Code" and click Next.
In the Client Information section, enter the Client ID and Client Secret from when you created the credentials in the Cloud Console. (If you forget, go to the Cloud Console API Credentials section and click on the pencil.)
For the Authorization URL, enter https://accounts.google.com/o/oauth2/v2/auth
For the Token URL, enter https://www.googleapis.com/oauth2/v4/token
Click Next
You now configure your client for the scopes that you're requesting. Unlike most other places you enter scopes - you need to have one per line. Then click Next.
You need to enter testing instructions. Before you submit your Action, these instructions should contain a test account and password that the review team can use to evaluate it. But you can just put something there while you're testing and then hit the Save button.
Configure API.AI
Over in API.AI, you need to indicate that the user needs to sign-in to use the Action.
Go to https://console.api.ai/ and select the project you're working with.
Select "Integrations" and then "Actions on Google". Turn it on if you haven't already.
Click the "Sign in required for welcome intent" checkbox.
Handle things in your webhook
After all that setup, handling things in your webhook is fairly straightforward! You can get an OAuth Access Token in one of two ways:
If you're using the JavaScript library, calling app.getUser().authToken
If you're looking at the JSON body, it is in originalRequest.data.user.accessToken
You'll use this Access Token to make calls against Google's API endpoints using methods defined elsewhere.
You don't need a Refresh Token - the Assistant should hand you a valid Access Token unless the user has revoked access.
After contacting Google the current situation seems to be that you should set up your own OAuth2 server, and then on the login screen of your OAuth2 server you should start the Google OAuth2 flow.
you have to have your own endpoint with Google Oauth2 - it is correct that you can't use Google Oauth itself as a provider. To use the Google OAuth service, you can use a "sign in with Google" button in your own endpoint instead.
Source: Contacting Google Actions on Google Support
Kind of speechless right now... as this seems to be a huge oversight on Google's part.
I am able to make it work after a long time.
We have to enable the webhook first and we can see how to enable the webhook in the dialog flow fulfillment docs
If we are going to use Google Assistant, then we have to enable the Google Assistant Integration in the integrations first.
Then follow the steps mentioned below for the Account Linking in actions on google:-
Go to google cloud console -> APIsand Services -> Credentials -> OAuth 2.0 client IDs -> Web client -> Note the client ID, client secret from there
-> Download JSON - from json note down the project id, auth_uri, token_uri
-> Authorised Redirect URIs -> White list our app's URL -> in this URL fixed part is https://oauth-redirect.googleusercontent.com/r/ and append the project id in the URL
-> Save the changes
Actions on Google -> Account linking setup
1. Grant type = Authorisation code
2. Client info
1. Fill up client id,client secrtet, auth_uri, token_uri
2. Enter the auth uri as https://www.googleapis.com/auth and token_uri as https://www.googleapis.com/token
3. Save and run
4. It will show an error while running on the google assistant, but dont worry
5. Come back to the account linking section in the assistant settings and enter auth_uri as https://accounts.google.com/o/oauth2/auth
and token_uri as https://accounts.google.com/o/oauth2/token
6. Put the scopes as https://www.googleapis.com/auth/userinfo.profile and https://www.googleapis.com/auth/userinfo.email
and weare good to go.
7. Save the changes.
In the hosting server logs, we can see the access token value and through access token, we can get the details regarding the email address.
Append the access token to this link "https://www.googleapis.com/oauth2/v1/userinfo?access_token=" and we can get the required details in the resulting json page.
accessToken = req.get("originalRequest").get("data").get("user").get("accessToken")
r = requests.get(link)
print("Email Id= " + r.json()["email"])
print("Name= " + r.json()["name"])
You need to implement the Oauth protocol with whatever Google Assistant app you are developing. Let me be a bit more clear:
The user is on the assistant, you need to link him to any data
you have on your App side
The access to the data you have about
your user is protected by an access token
Google then needs to
ask you for this token to have access to this resource
When
google has the token it can send it to the app so it validates every
requests to get the resource.
This is why you need to implement your own oauth server (Honestly it is just two more endpoints in your application): the identity is checked on google's side, but the link between the user and the resource to access can only be known by you.
The process above is valid, you just need to specify your own token endpoint and your own auth endpoint.
Note that if you only want to check that the user is logged in into google and get his email, you just need to implement the streamlined identity flow that does not require the /auth endpoint (Automatically Sign Up Users with Streamlined Identity Flows)
That beeing said I implemented the flow but get the same error :
expected_inputs[0].possible_intents[0]: Transactions/Identity API must be enabled before using.
Is AEM Authentication (closed user group) stateless ? What happens if we have multiple publisher, will the authentication handler ensure the user is authenticated in all the instance of the publisher ?
Could not find a document confirming this, So any help is appreciated.
Thanks.
The default AEM Authentication (CRX Login Module) is not stateless , the authentication is confirmed by a login token. When a user logs in the token information is stored under .tokens node of the corresponding user node (/home/users). The value of the token is also stored in the browser as a cookie login-token. Whenever a request comes in , the cookie value and the token in the repository is compared.[
You can test by deleting the .tokens node and refreshing some page that cannot be accessed by anonymous
]
In a multi publisher environment the token is created only on the instance which logged the user in. Since other instances cannot find the token for the cookie value in their repositories the request will be rejected.
If you enable sticky sessions , all requests by a particular client are always directed to the same instance.
Here's a page on Oak's token module . AEM uses crx token module but how they work is essentially same. Since your credentials are passed to a single instance by a form based authentication handler the token is created only in one instance. The authentication handler page also has some details on the token and the cookie.
UPDATE:
With AEM 6.1 , the authentication can now be made stateless as long as the user exists on all the publish instances. This is done by using a encrypted cookie that can be decrypted by all publish instances when they share the same HMAC key. More information can be found here : https://docs.adobe.com/docs/en/aem/6-1/administer/security/encapsulated-token.html
i think it´s possible if you activate the clustering on your authors, the .token node will be replicated to all instances and while comparing the users token ressource and the cookie the identification succeeds, this is one of the benefits of the jcr philosophy :all is content
Enable encapsulated token option in OSGI. Then it will authenticate seamlessly. But there are 2 prerequisite or conditions to get it worked. One is to put the same HMAC key on all the instances and secondly the user should exist. if these 2 conditions are met then if you login on one stack and the second stack wont required authentication again.