Mailing List Archive

On 10/25/2013 08:29 PM, 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.
>

Can you please send this patch as attachment.

Regards
Racke


--
LinuXia Systems => http://www.linuxia.de/
Expert Interchange Consulting and System Administration
ICDEVGROUP => http://www.icdevgroup.org/
Interchange Development Team


_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

On 2013-10-26, at 10:13 AM, Stefan Hornburg (Racke) wrote:

> On 10/25/2013 08:29 PM, 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.
>>
>
> Can you please send this patch as attachment.
>
See attached

Angus

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?

Thanks,
Jon

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

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

On 2013-10-30, at 9:37 AM, Jon Jensen 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.

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

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.

Angus,

Thanks for sending that last little patch along. That's helpful for seeing
what you're after.

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?

Thanks,
Jon

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

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

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.
>
> Angus,
>
> Thanks for sending that last little patch along. That's helpful for seeing what you're after.
>
> 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.

Angus

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/


_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

On 2014-06-11, at 6:50 PM, Jon Jensen wrote:

> 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.

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






_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

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/

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users