I am creating a token which I am passing as part of the url on a page. I encode t开发者_开发问答he string using rawurlencode() and send it as a token, however, I find that when I decode the received token (passed as a URL parameter), I get a slightly different string.
My url looks like this: /path/to/file.html?token=abcd123
Here is a snippet of the code I am using. Am I doing anything that is obviously erong?. Failing that, is there a better way to create (encrypted) tokens and pass them in the url?
<?php
//send
$raw = "some secret string";
$token = rawurlencode($raw);
//recieve
$data = rawurldecode($token);
?>
[Edit]
I have removed the enc(dec)ryption functionality - they were not the cause of the problem - and were a red herring. I have narrowed the problem down specifically to rawurlencode/decode not being symmetric in the way they are working.
A rawurlencoded string when decoded, is giving a different string (similar string, but with parts missing). Surely, there cant be a bug in something as fundamental to URLS - so I must be doing something wrong. Problem is that I can't spot it, and so far no one else seems to be able to spot it either ...
[Additional Info]
I am using the Symfony web framework (v1.3.8), which is probably messing with requests by encoding and decoding stuff behind the scenes. I am going to try to get the token parameter directly from the $_POST variable and see if Symfony is the culprit in all of this.
You shouldn't need to rawurldecode
the token when you receive it from the URL, because PHP handles that for you. e.g. "foo.php?q=hello%20world" results in $_GET['q']
having 'hello world' not 'hello%20world'
Since you're using ECB mode the IV is ignored, which is fortunate since you'd need to use the same IV to encrypt and decrypt.
As to what might be failing - the decrypted string will be padded to the block size so it might be longer than the original string. You can get around this by passing along the string length and using substr
after decryption.
精彩评论