Sorry, reply slipped. So it seems to be decoded twice in some way? %2B -> + and then + -> whitespace. But this seems to happen quite early in the request processing, much before it's handled by spring or cas. What am I doing wrong or is it all just very broken? :)
Thank you! Tom On Wednesday, 30 December 2015 11:45:17 UTC+2, Tom Andersson wrote: > > Hi, > > Thanks for the tips! > > It does indeed seem like a URL encoding or rather decoding issue. The > base64 data seems to have been url-encoded fine, the + characters are > encoded to %2B. However when the key reaches ClientFlowExecutionRepository, > It has been decoded so that the + characters have been replaced by > whitespace. It seems to be this way already after it's through > > > > On Tuesday, 29 December 2015 23:57:33 UTC+2, marvin.addison wrote: >> >> It seems like for some reason the execution key can not be decrypted. It >>> then tries to redirect me to an error page but it seems to start looping as >>> it still decrypt the execution. >>> >> >> Quick sanity check looks ok. The base64 data following the underscore in >> the flow execution ID is the encoded ciphertext; taking the length of that >> data and multiplying by 3 and dividing by 4 gives a whole number, which is >> correct. Obviously such a simple check isn't very reassuring, but it is a >> sanity check that rules out obvious truncation of the execution ID. >> >> >>> I'm pretty much out of ideas where to look next. Any pointers? >>> >> >> I'd rule out URL encoding errors before looking into decoding and >> decryption minutia. >> >> M >> >> -- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
