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/.
