[ic] ExtraSecure and special_pages/violation - PATCH

Jon Jensen jon at endpoint.com
Thu Jul 14 18:19:46 UTC 2016


Angus,

In going through some old email I found the thread forwarded below. I 
checked the mainstream Vend::Page code and don't see any evidence that it 
ever got patched with the changes we discussed.

Could you please attach a patch of the full diff between your Vend::Page 
and the mainstream one? Or you can just attach your entire Vend::Page if 
that's easier for you. Or a GitHub pull request would be great!

Anyway, I'd like to look this over again and get it committed to the 
Interchange Git repository if we can.

Thanks,
Jon


On Mon, 23 Jun 2014, Angus Rogerson wrote:

>> 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.
>
> Not yet. The code which uses this is working well on my development system. Hopefully we will upgrading to 5.8.x in the next few months, unless my priorities are changed again.
>
>> 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?
>
> I finally had to give in and learn about map, grep and sort (not so scary when you read: http://www.perlmonks.org/?node_id=675494). Your change makes a lot of sense to me now that I have read about BounceReferrals and BounceReferralsRobot. The sort makes the output pretty but probably is unnecessary.
>
> I have done preliminary testing on:
> diff -r1.4 Page.pm
> 123,125c123
> < 			map { "$_=$CGI::values{$_}\n" }
> < 			    grep { !$Vend::Cfg->{BounceReferrals_hide}->{$_} }
> < 				sort keys %CGI::values;
> ---
>> 			map { "$_=$CGI::values{$_}\n" } keys %CGI::values;
>
>> 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.
>
> I am actually referring from an https url to another https url which forces the user to authenticate against the university central authentication service using mod_auth_cas.
>
>>
>> If anyone objects, please speak up soon.
>>
>> Thanks,
>> Jon
>
>
> Thanks
>
> Angus
>
> ---
> Angus Rogerson, BMath, BScN, RN
>
> Duct Tape Programmer
> University of Waterloo | Retail Services | Information Systems
>
> Visit Us Online & Right On Campus www.retailservices.uwaterloo.ca

-- 
Jon Jensen
End Point Corporation
https://www.endpoint.com/



More information about the interchange-users mailing list