[ic] ExtraSecure and special_pages/violation

[Thomas J.M. Burton]

Jon Jensen wrote:
> On Wed, 16 Dec 2009, Thomas J.M. Burton wrote:
>
>> I've come across the issue of being able to access pages that are set
>> in the AlwaysSecure config setting using a direct URL and the http
>> protocol rather than https. From what I've been able to find on the
>> users list and in the docs, it appears that if ExtraSecure is enabled
>> and an AlwaysSecure page is accessed via http rather than https
>> (directly, from a browser's location bar), the user is redirected to
>> the special_pages/violation page.
>>
>> The problem that I see is that the violation page contains a login
>> form, indicating that the page is only accessible if they are logged
>> in. However, if an AlwaysSecure page is accessed directly through an
>> http url in the browser's address bar AND the user is already logged
>> in, the violation page is displayed with a "you are already logged
>> in" message.
>
> That sounds kind of confusing for users. :)
My thoughts exactly. It was confusing enough for me at first as a
developer! :)
>
>> From a look into lib/Vend/Page.pm, it would appear that the violation
>> special page is only called in a couple of specific cases, those being:
>>    - the requested page's name contains scripting characters
>>    - the requested page is set to be always secure, ExtraSecure is
>> enabled, and the page has been accessed via http
>>
>> If these are the only two circumstances that call the violation page, it
>> seems that a login form is not the appropriate content to deliver. Would
>> it not be more appropriate for the violation page to either redirect to
>> the requested page using https or display an error message?
>
> I can't think of why a login form would be there. It could be a relic
> from an older demo predating the Standard demo, because the
> dist/standard/special_pages/violation.html file hasn't changed since
> its initial import into version control.
>
>> Perhaps the decision to use the login form approach was intentional
>> in handling injection attempts. If that's the case, would it cause
>> any problems if the violation page's content were to be something
>> like the following?
>>
>> [if session shost]
>> ...standard violation content w/ login/logout messages & forms...
>> [else]
>> ...bounce to secure url of requested page ...
>> [/else]
>> [/if]
>
> I think that sounds good, except I'd remove the login form. Standard
> has its normal pages/login.html form that should be used.
>
> Can you put together an improved violation page and push it to a
> GitHub fork, or some other place we can get it?
I started tinkering with this yesterday and found that the approach I
mentioned above resulted in bad redirects if the user was sent to the
violation page due to a malformed URL (attempting to redirect to a
secure page that doesn't exist = unresolvable redirect).

Upon further evaluation, it seems that the most appropriate solution to
this would be to revise lib/Vend/Page.pm and change the way that
AlwaysSecure pages are handled when ExtraSecure is enabled.
Specifically, that would be lines 105-109:

         if($Vend::Cfg->{ExtraSecure} and
                 $Vend::Cfg->{AlwaysSecure}->{$name}
                 and !$CGI::secure) {
                 $name = find_special_page('violation');
         }

Rather than sending users to the violation page in that situation,
shouldn't it be redirecting the requested URL via https? Unless there's
a reason for sending those requests to the violation page, that would
seem like the most efficient solution. Otherwise, the checks performed
in Page.pm would need to be repeated in the violation page, which seems
redundant and inefficient.

If changing Page.pm would be the appropriate solution, I'm not sure of
the most efficient way to do so.

Further input on this would be greatly appreciated!

Thanks,
Tom

-- 
_______________________________
Global Focus Digital Media, LLC
www.globalfocusdm.com



!DSPAM:4b2a7821167893594411430!