[Building Sakai] Chrome 30 and HTTP

[Matthew Buckett]

Does Sakai think it's running on an HTTPS service? I think some tools
will look at the current request object and build the redirect based
on that. If your load balancer is using HTTP to talk to your Tomcat
servers then it may well be generating HTTP redirects.

I think you can force Sakai to generate HTTPS redirects even if the
request came in over HTTP with the system property:

sakai.force.url.secure=true

Another fix (I think) is to set the secure attribute on your HTTP
connector in your server.xml

<Connector acceptCount="100" connectionTimeout="20000"
disableUploadTimeout="true" enableLookups="false"
maxHttpHeaderSize="8192" maxSpareThreads="75" maxThreads="150"
minSpareThreads="25" port="8080" redirectPort="8443" secure="true"/>

Alternatively running the AJP protocol between your load balancer and
tomcat means that information about the original request (was it
secure) is correctly sent across.

This is all covered in the wiki page:

https://confluence.sakaiproject.org/display/DOC/Sakai+Admin+Guide+-+Advanced+Tomcat++(and+Apache)+Configuration

Could you give an example of requests that are generating redirects on HTTP?

On 4 October 2013 03:39, Matt Clare <Matt.Clare at brocku.ca> wrote:
> Hi Sakai-dev,
>
>         Have others seen issues with Chrome 30 (shipped yesterday), and HTTPS instances of Sakai and pages being blocked because the Sakai tool directed the user/Chrome to an HTTP link, not an HTTPS link?  All HTTPS proxy'ed/balence'd systems send an HTTP header to switch back to HTTPS in these instances, but Chrome 30 apparently deems this insufficient.
>
>         At Brock University we've noted this in our production 2.8 system in the Chat Room, Media Gallery, Section Info, Statistics tools and parts of Greadbook and Resources.
>
>         Grep'ing 2.8's source and 2.9.3's source there seems to be a number of hard-coded http://${server}/portal/tool/${tool_path}/overview.jsf type strings/URLs (less in 2.9.3) .  This would appear to be the cause of this issue (that and an over-zerlous Chrome team and the NSA).
>
>         My interpretation would be that there is no need for these type of URLs, either
>         /portal/tool/${tool_path}/overview.jsf
>         or
>         //${server}/portal/tool/${tool_path}/overview.jsf
>         would appear to be sufficient.
>
>         I'm interested if others are experiencing this issue with Chrome 30, what solutions they may have, and if my interpretation is accurate.
>
>         Thanks for your attention,
>
> .\.\att
>
>   ::  Matt Clare
> Manager, eLearning
>   Centre for Pedagogical Innovation
> Part-time Instructor
>   Interactive Arts and Sciences
> Brock University, Niagara Region, Ontario, Canada
> http://brocku.ca/pedagogical-innovation    905 688 5550 xt 4539   Office: SBH321
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"



-- 
  Matthew Buckett, VLE Developer, IT Services, University of Oxford