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