On confirmation page, use a hash parameter for SID.

This is a good suggestion that I think has been brought up before, but I couldn't find an exact issue for it. A better idea than hashing the SID parameter might be to add a second parameter (like "token") that must match in order for the user to access the page. So it would look something like this:

http://testsite/webform/confirmation?sid=1&token=234u235u02834

Drupal's existing token mechanism can create this hash key based on the current UID and the SID, making it difficult to spoof.

That said, no new features are being put into 2.x so I'm moving this to 3.x. In the mean time, I suggest you simply check that the $submission->uid and the $user->uid are the same, so user's are only allowed to look at their own submissions.

I have a contrary view for this. In the context of an email contact submission form, the confirmation page is a simple "Thank You" page that does not restate the submission. I was expecting Clean URLs to handle this and truncate/eliminate the session ID info. All submissions are "anonymous" on the site, as it is primarily informational. The added expression "?SID=x" is "too much information." Is it possible to eliminate this from the generated URL and not disrupt the form processing? I am not a php programmer. In my case, like this:

http://testsite/webform/confirmation

The ability to do this is also useful for Google Analytics goal setting. Thank you.

Another thought, maybe showing/hiding the SID info can be selectable within the admin interface.

Regards,

Mark Harrison

I find it hard to digest that ?sid=x is "too much information". Most users aren't even aware of the address bar. Have you ever looked at the URLs of Amazon.com or a search on Google?

From my perspective, I have two points of reference:

1) It breaks the Clean URLs functionality, in terms of SEO, that many of us are striving for. Sure, Amazon and Google, the 900-lb gorillas in town, don't have to be so concerned about this, but in my case, having multiple pages with the same content could negatively impact page rank. I understand that there is some "parameter handling" capability built into Google Webmaster Tools as well, but Clean URLs is Drupal 6 core functionality and not a third-party module. It should be preserved in your module as well.

2) In the context of this thread, @hacksersword has a concern about any given individual user with some savvy being able to edit/exploit the URL sid parameter to access data from previous submissions they should not be privy to, which is surely a security breach, regardless of how sensitive the data in question may be. Your proposition of additional code to protect @hacksersword's situation based on user IDs has two weaknesses to me: a) introduction of one or more additional variables to create a checksum that may or may not "work" out of the box and b) no apparent implementation for this in an "anonymous" environment, as in my case.

I think @hacksersword would have been less concerned in the first place if the sid paramenter wasn't visible in the URL to begin with. If the user were presented with the sanitized URL (read: shortened), why would he choose to introduce the variable. Once it is there, it becomes "fair game." But if it is not there, "out of sight, out of mind."

I maintain that the best, simplest and most elegant solution in this case happens at the source code for this module. I hope you will reconsider.

Regards,

Mark Harrison

I should hope that your confirmation page isn't being indexed by search engines anyway, or if it is, it probably has no effect on them. The search engine would need to fill out the form to actually get to the confirmation page that contains a hash in the URL. Using hashes is a 100% common solution for locking down URLs, include for anonymous users. See the way that Fivestar registers votes or Flag module counts flags. If it's a GET request, adding a hash is very common to help prevent unauthorized access to the page.

The addition of ?sid=x to the URL was originally a user-requested feature, since users that are not savvy developers would frequently use the PHP input filter on the confirmation message and get the SID out of the URL, since they have no context otherwise. If you're doing coding at the theming level, it's true the $_GET['sid'] is not necessary, since you already have the entire $submission variable available to you.

I have another problem. If the redirection address is ended with ?sid=x, the redirection is not effective, and "page not found" message appears.
What to do?

Hi,

I want to add my part to the issue...

In my case anonymous users submit a webform. This form redirects to a view, where thanks to sid I'm able to set filters in the view, which depend on the webform submission values.

This works fine, but visitors to the site are able to see information like how many submissions have been made since yesterday or even check out what kind of submissions people are making. This information is just not to be seen in public.

The idea to check the uid in #1 is good, but it's not working for anonymous users.

I'm not sure if this is right, but can the sid be sent as $_POST value instead as $_GET? This way it is not visible and can be accessed through a custom module.

Thanks for your ideas!

I'm not sure if this is right, but can the sid be sent as $_POST value instead as $_GET? This way it is not visible and can be accessed through a custom module.

That approach is not actually secure in any way, it's just "hiding" the issue. Using any number of simple tools users can submit POST requests just as easily as GET requests and access the same information. I'd suggest that you use Views' hooks or PHP fields to ensure that the SID that is used as a filter matches the user's submission IDs that they have completed for a truly secure solution.

@mru: See this issue for what you're wanting: #591902: Views filter: webform submitted by current user

EDIT: Actually that's maybe not quite the right thing. You'd want to filter webform submissions to "submitted by user", which is a bit different. In any case handling this at the Views layer seems like the most reasonable approach.

@quicksketch: thanks for your quick reply!

"I'd suggest that you use Views' hooks or PHP fields to ensure that the SID that is used as a filter matches the user's submission IDs that they have completed for a truly secure solution." - sorry to keep the issue alive, but how can I access the "user's submission ID" for an anonymous user? Is there somthing like this for anonymous users at all? Thanks!

but how can I access the "user's submission ID" for an anonymous user?

You can use the webform_get_submissions() function like this:

webform_get_submissions(array('nid' => $node->nid, 'uid' => $user->uid));

Even if the user's UID is 0, Webform makes an entry in the user's $_SESSION variable, making it so that it can ensure anonymous users access is valid. Or if you don't want to load the entire sessions themselves, checking $_SESSION['webform_submission'] is an easy way to get a list of SIDs for anonymous users.

I would like also to hide the sid... so users can't know how many submissions have been done... but now reading that the user could change the id and see results of other submissions is more concerning
I would like a change from http://testsite/webform/confirmation?sid=201 to http://testsite/webform/confirmation?token=234u235u02834
without the sid. add a column for the token in the database. and then look for the sid that corresponds to the token internally. without having it in the address bar.

I would like to hide sid from the confirmation page as well.

Evidently a lot of us need to hide the sid. I'm trying to use webform as a confirmation page that triggers a rule once submitted. I can't get to the custom url after the user submits the form because the sid at the end of the url goes to a "page not found".

As I was writing this I just had a thought, is there a way to do a redirect or an alias which will get me from your[added sid] url to my custom url.--customurl/node/20&sid=x changed to customurl/node/20

I'm using drupal 7

This is being added in #828566: Webform Token support on confirmation message.