Closed peterbe closed 10 years ago
This is a essentially a duplicate of #159 . Can we close this and move the discussion there?
Nah, this is a little different. #159 is about having a path in the URL(which we know is wrong), while this is about having a trailing slash(which might be acceptable).
I'm not sure if Persona would work when given a domain with a trailing slash; @peterbe , can you alter your local copy to not validate the audience and see if Persona works?
From what I gather from his log, I'm wondering, is it okay to allow for a trailing slash even though the incoming request domain doesn't have a trailing slash, only the SITE_URL setting does?
Is it okay to ever change the incoming domain, even if it's simply adding a slash? Are there any cases in which the incoming domain would have a trailing slash in it?
Changing the incoming domain on the request object isn't a good idea, considering how many other parts of Django use the request object. All we really care about is "Will Persona complain if we give it a SITE_URL that has a trailing slash?" The part that's failing right now is our own local validation, which in this case may be too strict (it fails when the trailing slash is there).
Ahhhh, that's a good distinction. I agree. We could account locally for the slash, but only send the incoming request domain over to Persona, since that's still technically the authorizing domain.
As of #202, the SITE_URL
setting has been replaced by BROWSERID_AUDIENCES
, which is matched using django.utils.http.same_origin
. I believe that should handle this! :D
Perhaps this has already been fixed in master but I'll leave it here so we don't forget: