[Building Sakai] Chrome 30 and HTTP

[Niebel, William (wdn5e)]

To clarify property (sakai.)force.url.secure:

(It looks like force.url.secure may have been used in entitybroker and the documentation needs cleanup to clarify or remove mention of it.
Speaking here from a 2.9.1 point-of-view.)

Instead (at least for kernel 1.3.1)
kernel/api/src/main/java/org/sakaiproject/util/RequestFilter.java doesn't use that property and uses instead property name
sakai.force.url.secure
(Thanks, Tim Sigmon, for pointing this out.)  See line 1512, at
https://source.sakaiproject.org/viewsvn/kernel/tags/kernel-1.3.1/api/src/main/java/org/sakaiproject/util/RequestFilter.java?view=markup

I only see sakai.force.url.secure used in RequestFilter and only in its method public static String serverUrl(HttpServletRequest req).
That method returns the server url (possibly fixed-up) of the request currently being serviced,
and not based on any configured domain, etc., of the running sakai server,
but conditioned only on sakai property sakai.force.url.secure
(Note that the single port given in that property is applied to any incoming request,
so using that property assumes what is probably the overwhelmingly common configuration of one domain name and one paired port being used for ssl.
That's us and that's most likely you.)

That method returns scheme/protocol + domain/ip + (:port), adding the port only if different from the usual mappings of
http => 80, https => 443.

Same method public static String serverUrl(HttpServletRequest req) is only used in that same RequestFilter class
in method doFilter() to
660: ThreadLocalManager.set(ServerConfigurationService.CURRENT_SERVER_URL, serverUrl(req));
and so whatever it sets there is available for reuse later by whatever class running however wired in or called
in servicing that same request (responding, redirecting, forwarding)
(Of course public static RequestFilter.serverUrl() might be called again instead downstream even during the same thread, in consideration that the request might have been subsequently wrapped and it would be safer or more appropriate to consider the serverUrl anew.)

In looking at this I noticed 2 classes which partially mirror this method, and which need to be remembered in fixing these problems with Chrome 30:
jsf/jsf-widgets/src/java/org/sakaiproject/jsf/renderer/CourierRenderer.java
kernel/kernel-util/src/main/java/org/sakaiproject/util/Web.java

public static String Web.serverUrl(HttpServletRequest req) simply returns RequestFilter.serverUrl(req);
and so presents no additional complication.  But . . .

private static String CourierRenderer.serverUrl(HttpServletRequest req)
comments that it is a copy of org.sakaiproject.util.web.Web.serverUrl()
but this copy evidently was done when Web.serverUrl() was itself a code copy (not just a call) of RequestFilter.serverUrl()
and that copy was itself made before RequestFilter.serverUrl() was conditional on sakai.force.url.secure

I also noticed a similar method public static String Web.returnUrl(HttpServletRequest req, String path)
again with code not conditioned on sakai.force.url.secure

So these last 2 methods may need to be reconciled to RequestFilter.serverUrl() to get the full sweep of any fix dependent on sakai.force.url.secure


Bill Niebel
University of Virginia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20131005/7562ab46/attachment.html