11.6
A webrequest (GET) sends a queryfield with: code=base64encodedstring&state=astringvalue
cCode = get-value('code').
cState = get-value('state').
everything seems to be ok, but since cCode is a base64-encoded string, it comes with a "=" at the end, but that is not retrived from get-value(). I have to do:
cCode = get-value('code') + '='.
to get correct value.
Is that ok to do? or is there another and better way doing this?
There are several characters in URLs that are considered "unsafe". The list includes ' " / \ ? & ; # = + (and maybe a more ). These are all delimiter characters and have special meaning. Having them appear in a value of a field is going to cause problems. Some of these are dependent on where in the URL they appear.
In your case the padding character for a base64 encoded value is treated as a delimiter in the query string. So any URL processing is going to chop this apart at the equals sign.
The sender needs to URL encode the value properly in order for it to make it through properly.
In base64 encoding, an "=" is added as padding. Depending on the size of the data being encoded, it may include, 0, 1 or 2 equal signs. If the equal sign is the only issue, then a more correct solution would be
cCode = get-value('code').
cCode = cCode + substring("==":U, 1, (length(cCode) * 3) modulo 4).
Do you need to strip off the padding? It is part of the spec.
Note that base64 is not entirely URL friendly by default. It allows forward slashes (/), equals (=) and plus (+) signs all of which are unsafe. If you're putting base64 encoded data into a URL, then you're expected to URL encode it to make it safe.
The wiki article above references a URL friendly variant...https://tools.ietf.org/html/rfc4648
I receive it, and I have been told it is base64. In the URL I am able to see the “=“ sign, but when using get-value the “=“ sign is not present...
Update from Progress Community
Matt Baker Do you need to strip off the padding? It is part of the spec.
Note that base64 is not entirely URL friendly by default. It allows forward slashes and + signs. If you're putting base64 encoded data into a URL, then you're expected to URL encode it to make it safe.
You received this notification because you subscribed to the forum. To unsubscribe from only this thread, go here.
Flag this post as spam/abuse.
There are several characters in URLs that are considered "unsafe". The list includes ' " / \ ? & ; # = + (and maybe a more ). These are all delimiter characters and have special meaning. Having them appear in a value of a field is going to cause problems. Some of these are dependent on where in the URL they appear.
In your case the padding character for a base64 encoded value is treated as a delimiter in the query string. So any URL processing is going to chop this apart at the equals sign.
The sender needs to URL encode the value properly in order for it to make it through properly.
Yes, I woke up with the same thought right now .. that is of course the problem. That’s why I can’t get the second parameter as well... thanks!!
Update from Progress Community
Matt Baker There are several characters in URLs that are considered "unsafe". The list includes ' " / \ ? & ; # = + (and maybe a more ). These are all delimiter characters and have special meaning. Having them appear in a value of a field is going to cause problems. Some of these are dependent on where in the URL they appear.
In your case the padding character for a base64 encoded value is treated as a delimiter in the query string. So any URL processing is going to chop this apart at the equals sign.
The sender needs to URL encode the value properly in order for it to make it through properly.
You received this notification because you subscribed to the forum. To unsubscribe from only this thread, go here.
Flag this post as spam/abuse.
