-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Terence,
On 11/1/14 3:44 PM, Terence M. Bandoian wrote:
> On 10/31/2014 11:18 AM, Mark Eggers wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>
>> On 10/31/2014 5:06 AM, Léa Massiot wrote:
>>> Hello and thank you for reading my post.
>>>
>>> I'm trying to make a webapp work with HTTPS. It was working
>>> properly with HTTP. Below is the problem I have.
>>>
>>> Inside a servlet, in its "doPost()" method, to check whether
>>> the "incoming JSP" is "example1.jsp" or "example2.jsp", I am
>>> using the following piece of code:
>>> -----------------------------------------------------------
>>> s_referer = request.getHeader("referer");
>>>
>>> if(s_referer.contains("example1.jsp") == true) { b_jspReferer1
>>> = true; } if(s_referer.contains("example2.jsp") == true) {
>>> b_jspReferer2 = true; }
>>> -----------------------------------------------------------
>>>
>>> In "example1.jsp" and "example2.jsp" there is a "<form>"
>>> element which "action" attribute is set to "do_example":
>>> -----------------------------------------------------------
>>> <form method="post" action="do_example"> [...] </form>
>>> -----------------------------------------------------------
>>>
>>> Now that I'm using HTTPS, "s_referer" is always equal to
>>> "do_example" in the servlet. Before, it used to be either
>>> "example1.jsp" in case the "incoming" JSP was "example1.jsp"
>>> and "example2.jsp" in case the "incoming" JSP was
>>> "example2.jsp".
>>>
>>> I don't know how to correct my code to be able to discriminate
>>> between the two JSPs. Can you please help me?
>>>
>>> I apologize in advance for the barbaric expression "incoming
>>> JSP". I hope my point is understandable despite unfortunate
>>> expression.
>>>
>>> Best regards.
>>>
>>>
>>>
>>> -- View this message in context:
>>> http://tomcat.10.x6.nabble.com/From-HTTP-to-HTTPS-request-getHeader-referer-tp5024782.html
>>>
>>>
>>>
>>
>>>
Sent from the Tomcat - User mailing list archive at Nabble.com.
>>
>> Times the referer will be empty:
>>
>> 1. entered the site URL in browser address bar itself. 2. visited
>> the site by a browser-maintained bookmark. 3. visited the site as
>> first page in the window/tab. 4. switched from a https URL to a
>> http URL. 5. switched from a https URL to a different https URL.
>> 6. has security software installed (antivirus/firewall/etc)
>> which strips the referrer from all requests. 7. is behind a proxy
>> which strips the referrer from all requests. 8. visited the site
>> programmatically (like, curl) without setting the referrer header
>> (searchbots!).
>>
>> Have you looked in various tools on the browser (developer tools
>> on Chrome, Tamper on Firefox, Fiddler on IE) to see if the
>> referer is being set?
>>
>> . . . just my two cents /mde/
>>
>
>
> Hi, Léa-
>
> Rather than relying on REFERER, you might consider using different
> action attributes in example1.jsp and example2.jsp. The targets
> could be minimal servlets that set a parameter and forward to
> do_example.
>
> Another approach would be to use hidden input elements in your
> forms (e.g. <input type="hidden" name="formId" value="1">).
+1
The Referer header is not reliable for anything.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUVWo/AAoJEBzwKT+lPKRYkuMP/0xNsWyEd8HwUO+GpzI9e5PE
YIHnWp9cp0zDvHnGTYwug5+mavcTDwpCoiGgGusd0Y+UUorz25hyx6AyAlGIcnNc
7aoYDe4tQHkclGiICGB+Ry3z/YO98P8bxwpMbLJEUxhVSLG7fRI6Viix8jfE9/74
8ssb3dr1yFhd2ATOxMfx5Pd23KTAC624JeSl39pWLpG20pvP29cJIk8aBoLbsKoz
w7yvkXZJGFBaEC4uRZ6jGGyGPYtxyt+oLfRO1MclPnEXzKTw9Wuck5uJnixWaPVo
3BcBq2AN7QWInZI4LmxCTf5I4qwOUK/vyBlXWez7dVdCiinJkNQ5Fu2kBGCpIu4d
7R9zlrE7uhcuPCFgi3lKrWk8SxpIxrpqfwN1P/SuHcneRY4uZZiKZdxDQcLOBpvi
olBdaldiu8XwXM9N3gSixI4W98NIhFQUtwgmLE//kkfILoo4oqzM5op81xZFWoxC
PI8UJhwwj14I83NZSHTyT1n1jVFpuEDiygRhXV4A1dklvdC6spH8STodgK0guFlD
/kDSPvgV0/AhThL7ja/iuEYOG7T1E5rYT3pA4YfbQn65TBuqmsabxxLt4kADMq+m
ADErQmkhJSPR8uM3dJy9ndy137UXFwi+b5R2iT7IuYgMB1TK3EPhQn6JMxtzlNxG
F/Y5OrX6lsbFVT4Uze1M
=g+8Y
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]