That's my understanding as well. Also stated in the javadocs of
https://docs.spring.io/spring-security/site/docs/4.0.3.RELEASE/apidocs/org/springframework/security/web/authentication/rememberme/PersistentTokenBasedRememberMeServices.html
"A suitable batch process should be run periodically
There's two ways to approach it. One is, as you're describing, to have a
central store of currently valid tokens, and check against that.
The other is to have tokens that contain information on what permissions
they grant and when they expire, with a cryptographic signature to prevent
tampering.
On Monday, January 22, 2018 at 9:07:20 PM UTC+13, Roland Weber wrote:
>
> On Saturday, January 20, 2018 at 12:08:16 AM UTC+1, Lawrence D’Oliveiro
> wrote:
>
>
Surely it’s the other way round, the usual practice being to maintain a
>> store of *valid* tokens, with a finite lifetime attached to
I spent some time digging into Spring to see how it is handled. They have
a PersistentTokenBasedRememberMeServices class. It generally follows this
standard approach
http://jaspan.com/improved_persistent_login_cookie_best_practice. The
article was a very interesting read and I think it may
I believe the use case and patterns for JupyterHub vs notebook could be
sufficiently different that we may want to look more into details.
IMHO having a set cookie to login to a notebook seem reasonable, as users
often only use it on localhost, and once you are logged-in you want your
login
On Saturday, January 20, 2018 at 12:08:16 AM UTC+1, Lawrence D’Oliveiro
wrote:
>
> Surely it’s the other way round, the usual practice being to maintain a
> store of *valid* tokens, with a finite lifetime attached to each (perhaps
> reset when they get presented again). The tokens get deleted
On Saturday, January 20, 2018 at 4:59:06 AM UTC+13, Tim Harsch wrote:
>
> ... we need to configure our app to have a persistent store of invalidated
> tokens to ensure they can't be re-used after logout.
>
Surely it’s the other way round, the usual practice being to maintain a
store of *valid*
I see your point. But the issue is compounded by the fact that since the
logout is occurring through the REST API, the browser still maintains the
cookie. So, after performing logout on command line I can go back to the
browser and continue to have access.
We recently underwent a security
I'm trying to understand the logout chain in jupyterhub/notebooks.
version 0.8.1 and 5.1.0 respectively. I'm using dockerspawner and
jwtauthenticator.
I would like to effect a logout from outside the UI, so I tried using the
API token and that doesn't seem to work as I get a 403. So I
