Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 UTC on 18 March 2024, to get $100 off your ticket.
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
Comments
Comment #1
quicksketchSeveral 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).
Comment #2
Katinka CreditAttribution: Katinka commentedWe 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?
Comment #3
quicksketchUnfortunately 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.
Comment #4
quicksketchComment #5
MJD CreditAttribution: MJD commentedI 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
Comment #6
jphelan CreditAttribution: jphelan commented%post is no longer working fro me either for anonymous users.
Comment #7
StevenWill CreditAttribution: StevenWill commentedI 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?
Comment #8
Alan D. CreditAttribution: Alan D. commentedThis 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: Allow hidden fields to handle unsafe tokens by making the "value" type fields, by the introduction of a value field. Value fields are never seen on the client side.
Comment #9
BenK CreditAttribution: BenK commentedDoes 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
Comment #10
quicksketchBenK, I'd suggest the issue Alan D. created: #630476: Allow hidden fields to handle unsafe tokens by making the "value" type fields.
Comment #11
quicksketchComment #12
maijs CreditAttribution: maijs commentedQuick workaround I found is to use javascript. As jQuery is quite standard in Drupal, it goes like this somewhere in your JS code:
You have to create hidden field componetent first of course. In this case it was called "referer" hence the id = 'edit-submitted-referer'.
Checking for empty string is because of webform may throw an error and in that case referer is going to be webform node itself.
Comment #13
halefxI've had a similar problem when trying to use session variables for anonymous users. The %server/%session tokens for anonymous users would have been really useful to me.
Comment #14
ronsnow CreditAttribution: ronsnow commentedI also would like to have access to the session variables for anonymous users. On my client's site, they are sending information from a item page to a webform to send emails. Session variables was how they were populating the variables and then these were automatically used by their webform, but not now.
Comment #15
CloudSociety CreditAttribution: CloudSociety commentedI'm a little late to the party on this one, but I've noticed that I can inject input fields into my mark-up by using the 'markup' type.
If you've enabled the php filter (and as anyone will tell you, be very careful with it's use), you can add the form item with your code.
As an example:
You still have the locked-in caching to contend with, but if you're bent on getting these variables back, this could do it.
On a side note for the caching thing... I'd assume a watchful developer can use the same technique as used for css and js caching. If you append ?RANDOMTEXT to the end of your url before hitting the contact page, it should skirt the cache. But I'm guessing there... the following example was tested briefly.
You might even add something like this to your htaccess file:
(also, Safari has some weird caching too. It really wants to store the page, but in Firefox, the date element changes every time)
Comment #16
Jenechka CreditAttribution: Jenechka commentedI am using ajax module with my webforms. Ajax ui has a small api.
Just add this to one of your .js files
Comment #17
quicksketchThanks for your suggestion Jenechka.
Comment #18
jmires CreditAttribution: jmires commentedWhere exactly do I put the code to pass the submitted form value through the url() function?
%get[q] is working just fine (in a hidden form input), but before the value is written to the db and e-mail is sent, I'd like to convert it to the full URL as seen by users. So rather than node/108 it would be something like http://mysite.com/my_descriptive_path
For the security reasons you outlined, using http://%server[HTTP_HOST]%server[REQUEST_URI] works great for logged in users, but these values are blank for anonymous users
Comment #19
mattiasj CreditAttribution: mattiasj commentedjmires did you find a solution for this? i am trying to achieve it as well.
Comment #20
kram08980 CreditAttribution: kram08980 commentedSuscribing, I also need a way to save the page which users are using to send the form (it's a Panels' page).
Sending node/3 with %get[q] is not what I want, but "xxxxxxxx.com/services/service3".
Comment #21
arbel CreditAttribution: arbel commentedsame problem, %get[q] returns the drupal path, how can I get the aliased version?
Comment #22
hassujoe CreditAttribution: hassujoe commentedI found an adequate solution for this by using inline javascript. These posts were very helpful:
http://drupal.org/node/296453#comment-3584946
http://drupal.org/node/342183#comment-2105788
First you need to enable PHP input format in modules.
Then enter something like this in the content -field of the webform in question.
where url is the name of the variable used to store the current path (windows.location.pathname) and FIELDNAMEHERE is the name of the webform field in which you want to input the path.
See http://www.devguru.com/technologies/ecmascript/quickref/location.html for details on windows.location.
Also, if the webform is a block, remember to enable display of the whole node in block settings.
Comment #23
sven_xo CreditAttribution: sven_xo commented#22 works fine for me
great :)
Comment #24
asad.hasan CreditAttribution: asad.hasan commented#18 works like a charm for me because i dun care about the aliased path in the email...i will keep the js in mind for other projects that demand it...
Comment #25
Hadi Farnoud CreditAttribution: Hadi Farnoud commentedfor some closed eco systems like drupalgardens, the url of the current page is quite handy and important since there is no way for injecting JS into them.
I have an exact feedback form at the end of each page. I used to collect feedbacks and had a hidden url field to find out which feedback is for which page. now it's broken! why is it a security issue? it should be ok.
Comment #26
quicksketchPlease do not reopen. This issue is being handled in #630476: Allow hidden fields to handle unsafe tokens by making the "value" type fields.