%server variable no more accessible by anonymous users
ermannob - October 15, 2009 - 16:12
| Project: | Webform |
| Version: | 6.x-2.9 |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
Hi,
In one of my website I have a public webform that needs the following variable to fill a field: %server[REQUEST_URI]. It's a webform for asking informations about the product displayed in a node.
With version 2.8, %server[REQUEST_URI] is no more accessible by anonymous users.
Is there a security reason for that? Am I wrong trying to make that variable public?
Any suggestions for a workaround?
Thanks a lot.
-ermanno
#1
Several server tokens presented security problems such as %server[HTTP_COOKIE] or %server[HTTP_REFERER]. As a work-around, I'd suggest using %get[q], which will tell you the Drupal internal path (which you can then run through the url() function to turn into a full, clean-url).
#2
We have a feedback webform, where users can post comments to some sites. We used the %server[HTTP_REFERER] token to identify the site the user comes from to add a feedback. This token replacement doesn't work any more after the security update to 5.x-2.8. The %get variable doesn't hold the referer information. Any suggestions what we can do?
#3
Unfortunately this was the exact sort of situation that caused the security problem (or more accurately, the privacy problem). If page caching is on (most of the time it is for a live site), then the value of %server[HTTP_REFERER] was also being cached, meaning it would appear as if all the users were coming from the same place unless the cache was cleared. It also meant that users could see where *other* anonymous users had come from, since it was probably in the HTML source.
If you need to have the $_SERVER['HTTP_REFERER'] value in the e-mails that are sent, I'd suggest theming the e-mails (as is documented in THEMING.txt), though unfortunately this doesn't help with storing these values in the database.
#4
#5
I am using %server[HTTP_REFERER] to record which page visitors were looking at before clicking on and submitting my contact page... All visitors are anonymous and I use the cache exclude module on my contact page to ensure the variable is updated....
Can I just confirm this was just a privacy issue and that this facility won't be making a comeback before I implement a work around that suits my needs....
it's not a privacy issue for me because if the visitor looks at the source they can only see where they came from....
Mark
p.s. I use drupal 6
#6
%post is no longer working fro me either for anonymous users.
#7
I need the same functionality as posted by MJD in post #5. Gathering the referer is a very common method and i need this for both the database, email and confirmation page. Is there a way to introduce the HTTP_REFERER into the field value in the template?
#8
This update broke a multisite install that runs from the same code / database source where the server name was vital in tracking the site that the web form was submitted by. Luckly, we could just switch to %site as all sites use a custom variable for site_name
But for those that need this, you should be able to use additional_validate field to update the $form_state. Maybe an introduction of a value FAPI field to handle all unsafe parameters would be a nice feature. These could be populated on submit on the server, removing the security risks.
I've opened this issue (no time to write a patch sadly), for a suggestion on how to record this info while bypassing the security issues: #630476: A value field for handling unsafe tokens, by the introduction of a value field. Value fields are never seen on the client side.
#9
Does anyone have a workaround for gathering the browser type of the user in a hidden field? I used to use "%server[HTTP_USER_AGENT]" in a prior version of Webform, but that no longer works.
Thanks,
Ben
#10
BenK, I'd suggest the issue Alan D. created: #630476: A value field for handling unsafe tokens.