[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Secure transport
To answer a question I was re-examining out secure transport mechanisms. It looks like the only runtime mechanism we provide allows a portlet to encode the secure transport requirement in its rendered URLs? Is this correct? Did we ever discuss trying to define a semantic [in BlockingInteraction] to allow a portlet to get equivalent behavior as defined by the flags in PortletDescription? Namely, the ability to ensure that all links on the page reflect the secure requirement vs just the one's in the portlet? If I understand things as we have them today, its possible for the portlet to switch to secure transport [via its URL] but then have the user interact with another portlet on the page that doesn't know/need secure transport. At this point the choices for the secure portlet are limited, for example it can revert to the non-secure page which caused it to enter, or render a screen that let's you re-eneter it in secure mode. Can anyone refresh my memory why we went this route vs trying to find hooks that allowed the portlet to switch the entire page into secure mode? Was it just too complicated on the consumer to keep track of this state as you interacted with different portlets with different requirements? Did we figure that most portlets in this situation would merely set the secureOnly flag and be done with it? -Mike-
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]