Open haudiobe opened 7 years ago
If the solution finally selected to address this issue is to require the comparison of URL encoded paths, then we shall mention that the URL encoding must respect the requirements of Chapter 2 of RFC 3986 (https://tools.ietf.org/html/rfc3986). Thanks
Nicolas proposed to have this reference too. This would be impacting this PR in PSUdaemon/URISigningSpec.
It seems OK to me to be a bit more explicit by pointing to this specification. @PSUdaemon what do you think?
Yeah, that makes sense. I will add the reference.
EDIT: Reference is now added.
Excellent, thanks !
Submitter: Nicolas Weil We would need to be very explicit about the fact that we require or don't require both end of the chains to URL_Encode the UPC parameter.
With special characters like the space one, it can lead to discrepancies between the token calculation and the token verification.
My suggestion is to mandate the use of non-URLencoded paths on both calcluation and verification phases of the token.