[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Secure URL handling JSR & WSRP
Hi Richard, I would prefer the semantic that you've defined below with the tri-state and will also bring this up in the JSR 286 EG to clearify this. Stefan Richard Jacob wrote: > It seems we have quite different semantics on JSR and WSRP concerning > PortletURL.setSecure() and wsrp-secureURL. > > The JSR defines that setting the setSecure(true/false) seems to indicate a > switch either to HTTP od HTTPS and setting nothing, i.e. not calling > setSecure() does not switch the secure mode. The JSR spec wording seems > also to diverge from the API description where the API says that setting > setSecure(false) indicates that the portlet does not need a secure > connection (but does not indicate that the portal should actually switch to > HTTP). > > In WSRP we don't seem to have a tri-state (secure, unsecure, don't > care/leave as is). What we currently say in the spec is: > "The value for the wsrp-secureURL is a boolean indicating whether the > resulting URL MUST involve secure communication between the client and > Consumer, as well as between the Consumer and Producer. The default value > of this boolean is “false”" > > Does that mean that not setting wsrp-secure on a rewrite URL means "switch > back to non-secure" or " i don't care / leave as is"? > We don't say anything what should really happen if wsrp-secure=false is > really set. > > Can we agree on a common semantics between both specs where we would have a > tri-state: > - true -> MUST be called over a secure channel > - false -> indicating preference to switch back to non-secure > - not-present -> don't care / keep communication as is > > Another implication of the current JSR semantics seems to be that portlets > might change the security for other portlets. Assume the following > scenario: > - portlet A has a link with setSecure(true) -> portal switches to HTTPS and > displays page with HTTPS > - portlet B on the same page has a link explicitly setting setSecure(false) > -> portal switches to HTTP and views A & B -> A needs to discover that the > request is not secure (PortletRequest.isSecure()==false) and does not > display its intended content. > Thus portlet B has "disabled" the display of portlet A with an URL > invocation on B. > How does it work with reverse proxies where communication between client > and proxy is HTTPS whereas between the proxy and the (consumer) portal is > HTTP? > This is however a standard HTTP & SSL problem here. > > Or is there an anticipation that the portal should keep some kind of state > and determine that some portlet on the page is in "secure mode" (because it > encoded a URL with setSecure(true) ) and thus prevent switching to HTTP on > invocation of B's URL? > This seems to be the case in WSRP where we say: > "Note that the Consumer’s aggregated page MUST be secure if any of the > Portlets whose content is being displayed on the page have indicated the > need for secure communication for their current markup." > > So from an interop perspective and those who try to map JSR & WSRP > semantics I would have the question: > - what do you expect when you set wsrp-secureURL=false? > - what do you expect when you do not set wsrp-secureURL > > Mit freundlichen Gruessen / best regards, > > Richard Jacob > ______________________________________________________ > IBM Lab Boeblingen, Germany > Dept. 2289, WebSphere Portal Server Development 1 > WSRP Team Lead > WSRP Architecture & Standardization > Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888 > > IBM Deutschland Entwicklung GmbH > Vorsitzender des Aufsichtsrats: Johann Weihen > Geschäftsführung: Herbert Kircher > Sitz der Gesellschaft: Böblingen > Registergericht: Amtsgericht Stuttgart, HRB 243294 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]