Serving content from HCP without setting session cookies

[ChrisPaine]

Hi,

I'd really like to be able to expose some content from my HCP account to the internet but not have HCP set cookies on it when it is requested.

Even using non-authenticated content, HCP still seems to set a cookie - eg:

1. Remote Address:210.80.140.227:443
2. Request URL:https://entjunglediscoverypartner.ap1.hana.ondemand.com/enterprisejungle/HomepageTiles/images/first-...
3. Request Method:GET
4. Status Code:200 OK
5. Request Headersview source
   1. Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
   2. Accept-Encoding:gzip,deflate,sdch
   3. Accept-Language:en-US,en;q=0.8,en-AU;q=0.6
   4. Connection:keep-alive
   5. Host:entjunglediscoverypartner.ap1.hana.ondemand.com
   6. User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.101 Safari/537.36
6. Response Headersview source
   1. Accept-Ranges:bytes
   2. Content-Length:4540
   3. Content-Type:image/png
   4. Date:Mon, 13 Oct 2014 04:11:31 GMT
   5. ETag:W/"4540-1413113585000"
   6. Last-Modified:Sun, 12 Oct 2014 11:33:05 GMT
   7. Server:SAP
   8. Set-Cookie:BIGipServerentjunglediscoverypartner.ap1.hana.ondemand.com=!Wjonifb/bNadplktoQj1pi3WDlnePHanj1YCK4n3KwsTwaQbnLRcwBKQKxplkcfPBA4VMrdB5929Ag==; path=/; httponly; secure

Is there any way to stop this behaviour? Problem is Safari refusing to surface any content from HCP if user has not authenticated/connected to HCP due to 3rd party cookie rules.

Any suggestions much appreciated!

Cheers,

Chris

[evilyeti · Accepted solution]

Hey Chris,

Let me confirm - your issue is that the complete iFrame gets blocked by Safari, not just that the session cookies are lost?

According to our experts - this comes from the default behaivor of HCP to leverage F5 BigIP Cookie Persistence. While I agree this does not bring much value neither when you have a single app instance nor when you have no application session established - it is the way how we load balance requests at large. However our assumption up to now was that it doesn't hurt and even in case the 3rd party cookie is lost - that's no issue at all for non-sticky requests like yours.

2 possible options going forward are:

- have a custom domain associated to your app, where we're flexible to tailor the load balancing behavior without affecting all the rest of the HCP users (you never know who has built already something relying on this implicit load balancing behavior).

- we from our side to re-evaluate how to handle session persistence for non-session-enabled requests by default for HCP (will clearly take time and considerable rollout effort if changes are introduced).

Best wishes,

  Krassi

[ChrisPaine · Accepted solution]

Hi Krassi,

if the content I want is an HTML page that I'm serving in an iFrame - yep the whole iFrame gets blocked by Safari.

I couldn't care less about the session cookies - but seems Safari behaviour isn't just to stop the cookies being read/set it is also to block any associated content.

Even when I'm just embedding an image that is sourced from HCP it is blocked

As soon as user has navigated to HCP - then Safari considers it a "trusted" third party and will load content and even allow it to set cookies, but until then I just get an empty iFrame.

If option 1 is possible whilst option 2 is considered that would be great - as I hope to see a future where I would like to have enough users of my app that load balancing becomes necessary (although on my side everything should be REST based for actual transfer of data so stickiness shouldn't be required.)

Can you let me know how to proceed?

Cheers,

Chris

[evilyeti · Accepted solution]

I believe with the recent HCP update - this should not be an issue anymore. We've revisited our practices with cookie polution and no longer send back load-balancing cookies for non-authenticated requests.

Therefore -now it's all in the hands of application developers whether they want to estalbish a session to the particular server or not.

best wishes,

  Krassi