In my Drupal Page I have one l() function as follows:-

l('View Comments','admin/comments', array('query' => array('commentid' => $rinap_comm['record_id'])

So in this case I am passing the argument to new page 'admin/comments' using 'commentid'. The url will look like this:-


In new page I will retrieve the value using

$commentId= $_GET['addUser'];

This is all fine to get and set argument using GET function. But I didn't find it secure way to transfer confidential information from one page to another as the value will get appended in URL which can be visible to everyone.

Can anyone please suggest if there is more secure way of passing the information without visible to end user? If possible please brief me the steps.

  • a less obvious (though no more secure!) option is to use a session variable - but at least it's not presented to the user like an argument would be
    – Geoff
    Commented Feb 23, 2015 at 3:40
  • Why is the comment ID confidential?
    – Les Lim
    Commented Feb 23, 2015 at 4:03
  • @LesLim. the OP is only using the comment ID as an example. He/she is looking for a general method to transfer confidental data between pages so that the user cannot read it. Commented Feb 23, 2015 at 5:25
  • 1
    But the example doesn't match the context, and I think that's relevant. If you are generating the URL server-side (with the l() function), why do you need to expose confidential information at all? All you need to expose is an ID that references the confidential data in the data store. Unless the ID itself confidential? (It could be, but the example doesn't say.)
    – Les Lim
    Commented Feb 23, 2015 at 5:46
  • @LesLim, good point! I've taken the liberty of expanding my answer with this method for passing confidential data between pages. Commented Feb 23, 2015 at 7:40

1 Answer 1


You can symmetrically encrypt the data into a cipher before sending it, and decrypt it at the receiving page. This will not stop anyone from seeing the encrypted data, but they will not have access to the encryption key and will therefore not be able to understand the data.

If the data to passed is short, the encrypted data can be passed in the URL. To use an URL, just base-64 encode the resulting cipher so it can be represented by a string (and base-64 decode it at the receiving end to get back the cipher). Remember to decrypt to convert from the cipher to the original cleartext.

If the data is too bulky to fit in an URL, you may use a session variable to transfer the cipher. Then you can skip the base-64 encode/decode step. A session variable is not secure. However, just as with the URL, encryption will keep the data confidential.

Or, you can simply use pass the data using the database. This requires you to create a very small custom module that associates the data with a token that does not give away any information (e.g. an integer). You then pass the token by means of the URL, e.g.:


The receiving page then use this token to look up the data in the database.

  • I'd suggest incorporating the base64 with something like mcrypt() as a plain base64 string is practically no encryption at all.
    – Darren
    Commented Feb 23, 2015 at 6:34
  • @Darren, that is not what I suggest. I suggest that you first encrypt it (e.g. with MCRYPT_RIJNDAEL_256, BASE_64 is not even on the list of ciphers available to mcrypt) , and then, to make sure the ciphertext is a string that can be used in an URL, you use base-64 to encode the resulting ciphertext. You have misread the answer. Commented Feb 23, 2015 at 7:01
  • Exactly what I meant, I read your answer wrong and thought that you were suggesting to just base64 encode it :-P
    – Darren
    Commented Feb 23, 2015 at 7:02
  • As per the post trail I can use base64_encode and base64_decode on top of MCRYPT_DES to secure the url arguments. Is my understanding correct? Commented Feb 23, 2015 at 17:03
  • @user1843970, yup. First encrypt using MCRYPT_DES to encrypt into cipher, then use base64_encode to encode (i.e. to make sure it is a string that can be used as an URL argument), transfer, then use base64_decode the received string to restore the cipher, and then finally decrypt using MCRYPT_DES to get back to the cleartext. Commented Feb 23, 2015 at 17:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.