Hello All,

The Cookie idea is now implemented in our services and protected resources
from Ambit services can be viewed in a browser again.

http://www.ideaconsult.net/web/ngn/blogs/-/blogs/browsing-protected-opentox-datasets

Best regards,
Nina

On 14 February 2011 09:58, Nina Jeliazkova <jeliazkova.nina at gmail.com>wrote:

> Hello All,
>
> I'm forwarding part of the discussion, regarding how to include
> OpenSSO protected image resources in a protected HTML report, and not
> confuse browsers.
>
> On 14 February 2011 09:40, Martin Guetlein
> <guetlein at informatik.uni-freiburg.de> wrote:
> > On Mon, Feb 14, 2011 at 7:45 AM, Nina Jeliazkova
> > <jeliazkova.nina at gmail.com> wrote:
> >> On 13 February 2011 19:12, Nina Jeliazkova <jeliazkova.nina at gmail.com>
> wrote:
> >>>
> >>> Martin, Vedrin,
> >>>
> >>> But there is still problem to solve for displaying images for reporting
> (and in ToxPredict as well) .  The /compound/id/image urls should be
> protected by AA . Currently they are not, but this will change soon, after
> we test the wildcard policies Andreas suggested last week.
> >>>
> >>> Then it will not be possible just to put the <img> tag in the html , as
> the browser will not be able to send the OpenSSO token.  Same is valid for
> ToxPredict and I am not happy to abandon the handy <img> tag, but not sure
> if there is a good solution making use of it ... perhaps subjectid in the
> URL again :(
> >>>
> >>
> >> Got a bright new idea this morning how to make the browser transfer
> >> the subjectid and not beingf visible in the URI- by plain old cookies
> >> !
> >>
> >> A cookie, containing subjectid, would be optional / additional  to
> >> subjectid in the header.
> >>
> >> The server resource receives a GET request with  -H "subjectid:123".
> >> The response inclides subjectid as a cookie (might be with expiration
> >> time less than the token itself)
> >>
> >> Set-Cookie: subjectid=123
> >>
> >> Then the browser will resend this cookie in subsequent requests, by
> >> setting the Cookie header
> >>
> >> Cookie: subjectid=123;
> >>
> >> The server resources need to be modified to look for Cookie:
> >> subjectid= header as well, this might be restricted to HTML content or
> >> just have less priority than subjectid: header.
> >>
> >> As cookies go in the header,  same security considerations apply, as
> >> to the current solution.
> >>
> >> What do you think about it?
> >>
> >> Best regards,
> >> Nina
> >
> >
> > Hi Nina,
> >
> > sounds very good to me.
> >
> >> Then the browser will resend this cookie in subsequent requests, by
> >> setting the Cookie header
> > That would be brilliant as it would solve the problem of protected
> > resources, that are linked in the report.
> >
> > And I think it is quite easy to implement, and it would allow the
> > reports to stay accessible independently.
> >
> > I will certainly give that a try.
> >
> > Regards,
> > Martin
> >
> >
>
> Let's discuss cookies during  today's meeting :)
>
> Nina
>