I presume you are refering to the following line in section 10.2.1.7:
"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."
Its not clear what this means. Is it merely a requirement that the
page response be over a secure channel if the portlet/page request was
secure? Or does it say that once in a portlet's secure link is invoked
the Consumer must keep the page in secure mode until the portlet that
went into secure mode, leaves it? I.e. must find a way that all
subsequent links on the page use https? The former seems obvious. The
later seems a major pain for Consumers as you potentially have to
manage a stack of states. Can you clarify?
-Mike-
Rich Thompson wrote:
We did discuss having a return field
from pbia that required the page to use secure communications. We
decided
against it due to the small set of use cases where it would be
significant
and the overall impact of requiring the Consumer to redirect the user
agent
at that point in the process of building a new page.
There is a requirement in 10.2.1.7
(wsrp-secureURL
definition) which requires that the secure communications be used for
delivering
the page to the user when any portlet has specified that secure URLs be
used. Basically this allows Consumers to support other Portlet's URLs
not
being secure if a redirect to a secure version of the page happens
(likely
improves fragment cachability) or Consumers can rewrite all URLs to use
secure references (would require that all Portlet's use Consumer URL
rewriting).
Rich
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-
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|