Mailing List Archive: RFC: New AlwaysSecureGlob directive

RFC: New AlwaysSecureGlob directive

jon at endpoint

Mar 25, 2017, 4:56 PM

Post #1 of 9 (2601 views)

Interchangers,

Before I push it to the main repository I'd like to solicit any feedback
you all may have on a new catalog directive "AlwaysSecureGlob", which is
the same as AlwaysSecure but allows shell-style glob wildcards * and ? to
be used, and requires comma-separation as other similar directives do
(such as RobotUA).

The AlwaysSecure directive requires an exact match of the page name and
it's not possible to enumerate all the admin URLs or ActionMaps that
should be generated secure-only, so this new directive makes that possible
with wildcard matching.

The commit:

https://github.com/jonjensen/interchange/commit/b498ab78fabd77784f216e7f1dc050e5da5e52a9

Thanks,
Jon

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

Re: RFC: New AlwaysSecureGlob directive [ In reply to ]

peter at pajamian

Mar 25, 2017, 5:17 PM

Post #2 of 9 (2601 views)

On 26/03/17 12:56, Jon Jensen wrote:
> The AlwaysSecure directive requires an exact match of the page name and
> it's not possible to enumerate all the admin URLs or ActionMaps that
> should be generated secure-only, so this new directive makes that
> possible with wildcard matching.

I like this idea but I think it's time is fast passing. Recommendations
nowadays (especially with pushes from Google, etc) are that the *entire
site* should be served up as https, and this is easily done with an
httpd redirect and setting VendURL to https://... So with that in mind
specifying which pages should always need to be secure becomes a bit
pointless.

Peter

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

Re: RFC: New AlwaysSecureGlob directive [ In reply to ]

jon at endpoint

Mar 25, 2017, 5:38 PM

Post #3 of 9 (2601 views)

On Sun, 26 Mar 2017, Peter wrote:

> On 26/03/17 12:56, Jon Jensen wrote:
>> The AlwaysSecure directive requires an exact match of the page name and
>> it's not possible to enumerate all the admin URLs or ActionMaps that
>> should be generated secure-only, so this new directive makes that
>> possible with wildcard matching.
>
> I like this idea but I think it's time is fast passing.
> Recommendations nowadays (especially with pushes from Google, etc) are
> that the *entire site* should be served up as https, and this is easily
> done with an httpd redirect and setting VendURL to https://... So with
> that in mind specifying which pages should always need to be secure
> becomes a bit pointless.

I agree that the time is fast passing, and on every new site we make we do
use HTTPS only. Much simpler all around.

But for many legacy sites it's still going to be years before we can do
that due to numerous dependencies on the plain HTTP URLs.

In the meantime the old AlwaysSecure directive just doesn't work for huge
classes of URLs and I keep finding legacy sites where internal admin URLs
are pointing to plain http: and then getting redirected back to https,
leaking data along the way or failing if ExtraSecure is set.

Jon

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

Re: RFC: New AlwaysSecureGlob directive [ In reply to ]

peter at pajamian

Mar 25, 2017, 6:22 PM

Post #4 of 9 (2601 views)

On 26/03/17 13:38, Jon Jensen wrote:
> But for many legacy sites it's still going to be years before we can do
> that due to numerous dependencies on the plain HTTP URLs.

This depends largely on sites dependence on hard-coded URLs. If sites
(even legacy ones) stick the use of the [area] tag and other mechanisms
that check VendURL then the transition is relatively easy.

That said, I'm not opposed to adding this directive, I think it's a good
idea and don't see any particular issues with the functionality itself.
I just think that if someone is going to use it it may very well be a
good time to re-think your approach and consider a change to full https
instead.

Peter

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

Re: RFC: New AlwaysSecureGlob directive [ In reply to ]

jon at endpoint

Mar 25, 2017, 6:30 PM

Post #5 of 9 (2601 views)

On Sun, 26 Mar 2017, Peter wrote:

> On 26/03/17 13:38, Jon Jensen wrote:
>> But for many legacy sites it's still going to be years before we can do
>> that due to numerous dependencies on the plain HTTP URLs.
>
> This depends largely on sites dependence on hard-coded URLs. If sites
> (even legacy ones) stick the use of the [area] tag and other mechanisms
> that check VendURL then the transition is relatively easy.

No, it's not because of that at all. There are no hardcoded URLs in the
site this was developed for.

It's needed because of 3rd-party external stuff (analytics, remarketing,
etc.) that doesn't work with HTTPS yet, which requires parts of the site
to stay plain HTTP. That which means [area] has to be able to generate
both HTTP & HTTPS.

Jon

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

Re: RFC: New AlwaysSecureGlob directive [ In reply to ]

peter at pajamian

Mar 25, 2017, 6:59 PM

Post #6 of 9 (2601 views)

On 26/03/17 14:30, Jon Jensen wrote:
> It's needed because of 3rd-party external stuff (analytics, remarketing,
> etc.) that doesn't work with HTTPS yet, which requires parts of the site
> to stay plain HTTP. That which means [area] has to be able to generate
> both HTTP & HTTPS.

Hrmmm, ok, I never had that issue when converting sites, but then I
haven't done that many yet. If I ever have to cross that bridge I'm
sure I'll find some sort of solution.

Peter

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

Re: RFC: New AlwaysSecureGlob directive [ In reply to ]

racke at linuxia

Mar 26, 2017, 6:16 AM

Post #7 of 9 (2600 views)

On 03/26/2017 12:56 AM, Jon Jensen wrote:
> Interchangers,
>
> Before I push it to the main repository I'd like to solicit any feedback you all may have on a new catalog directive
> "AlwaysSecureGlob", which is the same as AlwaysSecure but allows shell-style glob wildcards * and ? to be used, and
> requires comma-separation as other similar directives do (such as RobotUA).
>
> The AlwaysSecure directive requires an exact match of the page name and it's not possible to enumerate all the admin
> URLs or ActionMaps that should be generated secure-only, so this new directive makes that possible with wildcard matching.
>
> The commit:
>
> https://github.com/jonjensen/interchange/commit/b498ab78fabd77784f216e7f1dc050e5da5e52a9
>
> Thanks,
> Jon
>
>

Yes, fair enough.

I agree with Peter that websites nowadays should use https:// only as far as it goes.
But that isn't always possible, e.g. Amazon MWS requires product http:// for images.

Of course rewriting of these links could also happen at web server level. It would be
a tad more efficient there, as well.

Regards
Racke

--
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration.

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

Re: RFC: New AlwaysSecureGlob directive [ In reply to ]

jon at endpoint

Mar 27, 2017, 8:32 AM

Post #8 of 9 (2593 views)

On Sun, 26 Mar 2017, Stefan Hornburg (Racke) wrote:

>> Before I push it to the main repository I'd like to solicit any
>> feedback you all may have on a new catalog directive
>> "AlwaysSecureGlob", which is the same as AlwaysSecure but allows
>> shell-style glob wildcards * and ? to be used, and requires
>> comma-separation as other similar directives do (such as RobotUA).
>
> Of course rewriting of these links could also happen at web server
> level. It would be a tad more efficient there, as well.

You'll have to explain what you mean by this. I don't understand.

I can't see how having the web server parse the HTML response page and
rewrite the links (a brand new step the site is not doing now) could
possibly be faster than just having Interchange output the correct URL we
want in the first place.

Jon

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

Re: RFC: New AlwaysSecureGlob directive [ In reply to ]

racke at linuxia

Mar 27, 2017, 11:56 PM

Post #9 of 9 (2593 views)

On 03/27/2017 05:32 PM, Jon Jensen wrote:
> On Sun, 26 Mar 2017, Stefan Hornburg (Racke) wrote:
>
>>> Before I push it to the main repository I'd like to solicit any feedback you all may have on a new catalog directive
>>> "AlwaysSecureGlob", which is the same as AlwaysSecure but allows shell-style glob wildcards * and ? to be used, and
>>> requires comma-separation as other similar directives do (such as RobotUA).
>>
>> Of course rewriting of these links could also happen at web server level. It would be a tad more efficient there, as
>> well.
>
> You'll have to explain what you mean by this. I don't understand.
>
> I can't see how having the web server parse the HTML response page and rewrite the links (a brand new step the site is
> not doing now) could possibly be faster than just having Interchange output the correct URL we want in the first place.
>
> Jon

Yeah, please strike my comment :-).

Regards
Racke

--
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration.

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