> On Jun 24, 2019, at 15:44, Jonathan Vanasco <jonat...@findmeon.com> wrote: > > > On Friday, June 21, 2019 at 8:43:32 PM UTC-4, Mike Orr wrote: > But if I want to contribute to the enterprise's Single Sign-In, do I need to > tell the server the user is still logged into my application so it > doesn't expire the SSO account?
No. This is not something that the refresh token/access token is concerned with. > > That is up to your upstream identity provider. > > Your token should be assumed valid until the expiry timestamp. The upstream > provider may have it's own protocol where you are supposed to check validity > at periodic intervals. > > > Do I do this by refreshing the token? > No. > > If I do want to refresh the token, do I do it in a NewRequest subscriber? > Generally this is done by a background process. If you want to do it within > a Pyramid request, you could do it in a tween or subscriber. See my question below... you likely don't need to do any refreshing > > The refresh_expire is 60 minutes, so how close to the end should I do > the refresh? If a request comes in 10 minutes before the end, I don't > know whether the next request will be in 1 second or 20 minutes. > > This is largely an organizational issue on how long you can honor the tokens. > TBH, expiring a refresh in 60 minutes sounds like a bad configuration. > Typically an access token would expire in 60 minutes, but the refresh token > would expire in 30 days. That would mean you would need to automatically > refresh the access token behind-the-scenes every 60 minutes. > Mike, before you try to go through the whole rigamarole of using the refresh token to update the access token, let me ask you an important question: Are you using the access token after you fetch the initial information about the user from Keycloak? If you NEVER ever make another request to Keycloak as long as the user is logged in to your Pyramid application, then you don't need to worry about refreshing the access token. In which case you can just discard it and the refresh token. If you ever need another access token you'd basically make the user do the login dance again. At that point keycloak will go "Ah, but the user is already logged in, and already authorized this application" and fast forward back to your application, you get a new access token, you contact Keycloak and then forget about it ever again. > > What if the request contains POST data? Would I have to save the data in > the session, generate an authorization URL, redirect to the server, > come back through the callback view, redirect back to the original > URL, and extract the POST data in the session. (Where it's no longer > in request.POST.) That sounds like a lot of code overhead. > > If you need the user to re-authorize because your refresh token expired... > you would need to stash the POST data, so that is one way of doing it. That > is a lot of overhead, but should not happen because the refresh token should > live longer. This is the case even if the refresh token hasn't expired. If the user's session has expired (for any reason what so ever). It's up to you to decide whether to save the users input or if it is lost while they do the login/auth dance again. > > I may also have to put a session lock in the site; i.e., Javascript > that waits for an idle timeout and puts up a modal dialog, "Do you > want to extend your session?" or "Your session is expired. Click here > to log in again." How would that interact with tokens and refreshing > tokens, since my token processing is in the backend? > > If you have csrf field on the form, that csrf token might have changed. You > could update it with javascript. > > How could the Javascript extend the session or have the user log in again > without > throwing away a partially-filled-in form? > > Do the reauth in an ajax request or a browser popup. > > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to pylons-discuss+unsubscr...@googlegroups.com > <mailto:pylons-discuss+unsubscr...@googlegroups.com>. > To post to this group, send email to pylons-discuss@googlegroups.com > <mailto:pylons-discuss@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/pylons-discuss/6eb8c654-073d-428d-b404-2fb22d751092%40googlegroups.com > > <https://groups.google.com/d/msgid/pylons-discuss/6eb8c654-073d-428d-b404-2fb22d751092%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discuss+unsubscr...@googlegroups.com. To post to this group, send email to pylons-discuss@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/BE4C4DF9-7A44-4E3C-9190-3A42C11FA3CE%400x58.com. For more options, visit https://groups.google.com/d/optout.