[ic] ExtraSecure and special_pages/violation - PATCH
Jon Jensen
jon at endpoint.com
Wed Jun 11 22:50:41 UTC 2014
Angus,
Following up on a long-dormant thread ...
On Thu, 14 Nov 2013, Angus Rogerson wrote:
> On 2013-11-13, at 10:37 AM, Jon Jensen wrote:
>
>> On Wed, 6 Nov 2013, Angus Rogerson wrote:
>>
>>>> On Fri, 25 Oct 2013, Angus Rogerson wrote:
>>>>
>>>>> In an email exchange ending with
>>>>> http://www.icdevgroup.org/pipermail/interchange-users/2009-December/051506.html,
>>>>> Jon and Tom described a solution for better behaviour for the
>>>>> ExtraSecure feature.
>>>>>
>>>>> In an email
>>>>> http://www.icdevgroup.org/pipermail/interchange-users/2013-May/054042.html,
>>>>> Paul hints at the need for similar functionality.
>>>>>
>>>>> The patch below implements this feature in 5.8.0. Sorry, I don't
>>>>> have git.
>>>>>
>>>>> With this patch, the user gets a 301 redirect to the secure version
>>>>> of the page instead of the violation page. The logGlobal uses some
>>>>> non-standard CGI values which would need to be added to @Map in
>>>>> Vend::Server.
>>>>
>>>> Thanks for sending that, Angus. You mention that you needed to change
>>>> something in Vend::Server. Will you please send a patch for that too
>>>> so we can consider the whole set of changes together?
>>>
>>> Sorry about the delay. Please find attached patch which adds
>>> script_uri to list (@Map) of environment variables to copy to CGI.
>>> This is used to log anytime the bounce happens so we can identify who
>>> is sending people to the non-secure page.
>>
>> I'm a little confused about exactly what is going on here. The
>> SCRIPT_URI environment variable you're using only exists when Apache's
>> mod_rewrite was in effect for the request, which is far from the only
>> way requests pass through to Interchange.
>>
>> That is explained here:
>>
>> http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html
>>
>> I could see the patch making sense if it can use one of the standard
>> environment variables Interchange already has. Is there one that would
>> work, or one of the catalog path configuration variables, or something?
>
> We use mod_rewrite in our installation so I didn't realize others did
> not have access to SCRIPT_URI. Please find attached a revised patch
> which does not use script_uri, just the referer. This patch does not
> require any changes to Vend;:Server.
>
> Since users are now being redirected to the correct secure version of
> the page anyway, it is not terribly important to be able to track down
> who might be linking to a non-secure version of our page. If for some
> reason it was important, then it should be possible to use the time the
> error is logged and the referer to find the offender in the web server
> logs.
Are you using the patch you submitted on a production website? If so, I'd
still like to get this committed to Interchange so you don't have to
maintain a forked version.
I noticed something in the patch that you brought over from the
BounceReferrals code that I don't think belongs here:
grep { !$Vend::Cfg->{BounceReferrals_hide}->{$_} }
You're excluding URL query parameters that are excluded from
BounceReferrals redirects, but I don't think any parameters should be
excluded on a redirect from http to https. So I would remove that grep. Do
you see any problem with that?
Otherwise, I think this should be fine. There has been some debate about
whether redirecting users from http to https automatically is a good idea
or not:
http://security.stackexchange.com/questions/49645/actually-isnt-it-bad-to-redirect-http-to-https
But everyone seems to agree there is no reasonable alternative given
current browser behaviors, so I'm inclined to say this is a usability
improvement worth making.
If anyone objects, please speak up soon.
Thanks,
Jon
--
Jon Jensen
End Point Corporation
http://www.endpoint.com/
More information about the interchange-users
mailing list