Drop token from URL after login about django-sesame HOT 19 CLOSED

It's technically possible to add this feature to the middleware.

I'm wondering if it needs to be configurable or if we should just make a choice here.

That choice is a tradeoff between page load time (an extra redirect) and URL cleanliness.

Currently django-sesame supports running without django.contrib.sessions (theoretically — I never tested it and I don't expect anyone to do that). We shouldn't redirect in that case.

from django-sesame.

I pushed version 1.4 to PyPI with this feature.

from django-sesame.

I can't imagine many scenarios where I'd want to keep the token in the URL.

I'm building an app (nothing sensitive and well within the security caveats) that will generate unique event URLs to be shared via text/chat/etc. and take advantage of the password-less login provided by this package. If the token remains in the URL, it increases the chances that someone will share a URL that inadvertently logs in as that user.

from django-sesame.

Agreed, that's why I'm thinking it could be the default behavior (with no option to change it).

That would require modifying this block:

to add something like:

    # deconstruct URL
    # remove url_auth_token parameter
    # reconstruct URL
    # redirect

from django-sesame.

👍 That flow is very similar to what I've implemented in another app to achieve this effect.

from django-sesame.

PR welcome :-)

NB - you'll need to tweak __call__ as well.

from django-sesame.

Should the token be removed from the URL if authentication fails?

from django-sesame.

Good question! Probably not?

from django-sesame.

I think I agree. The PR I submitted keeps the token on failed auth.

from django-sesame.

Unfortunately this is not working for safari, as it is against setting cookies in 302 redirects.

When someone wraps the url with the token (for example to make a bit.ly short url, or an automated url defense software ) it fails in safari (both ios and desktop.)

from django-sesame.

is there any chance for you to make this optional ?

from django-sesame.

This sounds like a side-effect of the over-zealous "Protection Against First Party Bounce Trackers" in ITP 2.0.

Do all redirects happen on the same domain? Or do you change first-party domain e.g. from https://example.com/ to https://www.example.com/?

from django-sesame.

The domain was different, which Is probably the case when you do url shortening, same goes for url defenders.

Unfortunately this failed for us in the middle of a huge demo when the guys tried using it with their corporate email (which uses proof point.com)

from django-sesame.

To be honest I'd rather implement something that works well for most users rather expect them to learn the intricacies of ITP and determine that they may need to tweak a setting.
`
Perhaps we could redirect only in circumstances that are deemed "ITP-safe", for example when there is no referrer from a different domain — there should be one from proofpoint.com in your example.

from django-sesame.

I think that's fair enough.

from django-sesame.

For the record, there've been several discussions of ITP on the django-developers mailing-list. Apparently there are many use cases where ITP is over-zealous and blocks perfectly legitimate behavior.

from django-sesame.

Probably we should just sniff the user agent disable the redirection on Safari... It isn't critical to django-sesame's functionality.

from django-sesame.

That would have been a good plan if it had been possible to detect Safari reliably with its user agent...

from django-sesame.

Does #22 work for you? Don't forget to pip install ua-parser, else it won't do anything.

I didn't make ua-parser a mandatory dependency because I'm not comfortable adding 0.2-0.5s to the boot time of every app that uses django-sesame just because Safari is annoying.

from django-sesame.