How to preserve the session id whether the http request header contains 'Pragma'='no-cache'.

The new session id is created when the http request header contains

‘Pragma’=‘no-cache’ on our RoR environment. Our goal is that the session

id is preserved if the http request header contains ‘Pragma’=‘no-cache’.

Please let us know how to preserve the session id.

The detailed sequence is shown below:

  1. The user downloads the Microsoft World file from RoR application, and

opens that file using ‘Protected View’.

  1. The user clicks the url link which is written in that Word file. The

clicked url link points to a page which is located on that RoR

application.

  1. On opening that url link, the http request header contains

‘Pragma’=‘no-cache’, and the new session id is created with the http

response header which contains ‘Set-Cookie’.

If the user opens that file not using ‘Protected View’ on the sequence 1,

the session id is preserved on the sequence 3. The http request header

doesn’t contain ‘Pragma’=‘no-cache’.

The our RoR environment is shown below:

Server:

Rails 3.2.14, and ruby 2.0.0p247 on apache 2.2.29, and unicorn 4.6.3

Clients:

Internet Explorer 8, and MicrosoftOffice 2010 on Windows7 64bit.

Does the request in 3 have a cookie header?

Fred

I can’t find much documentation for Protected View, but there’s some indication that it may be fiddling with the context that the web request uses when you click on the link:

https://onmessages.wordpress.com/2015/01/19/a-security-problem-has-occurred-in-word/

This may be a security restriction to prevent malicious documents from including hyperlinks to third-party sites that rely on the user’s existing cookies to do XSS.

–Matt Jones

2015年8月5日水曜日 19時52分01秒 UTC+9 Frederick Cheung:

The new session id is created when the http request header contains

‘Pragma’=‘no-cache’ on our RoR environment. Our goal is that the session

id is preserved if the http request header contains ‘Pragma’=‘no-cache’.

Please let us know how to preserve the session id.

The detailed sequence is shown below:

  1. The user downloads the Microsoft World file from RoR application, and

opens that file using ‘Protected View’.

  1. The user clicks the url link which is written in that Word file. The

clicked url link points to a page which is located on that RoR

application.

  1. On opening that url link, the http request header contains

‘Pragma’=‘no-cache’, and the new session id is created with the http

response header which contains ‘Set-Cookie’.

If the user opens that file not using ‘Protected View’ on the sequence 1,

the session id is preserved on the sequence 3. The http request header

doesn’t contain ‘Pragma’=‘no-cache’.

Does the request in 3 have a cookie header?

Fred

Thank you for your quick response. The request in 3 does not have a

cookie header if the open mode is ‘Protected View’ or not.

2015年8月6日木曜日 4時32分05秒 UTC+9 Matt Jones:

The new session id is created when the http request header contains

‘Pragma’=‘no-cache’ on our RoR environment. Our goal is that the session

id is preserved if the http request header contains ‘Pragma’=‘no-cache’.

Please let us know how to preserve the session id.

The detailed sequence is shown below:

  1. The user downloads the Microsoft World file from RoR application, and

opens that file using ‘Protected View’.

  1. The user clicks the url link which is written in that Word file. The

clicked url link points to a page which is located on that RoR

application.

  1. On opening that url link, the http request header contains

‘Pragma’=‘no-cache’, and the new session id is created with the http

response header which contains ‘Set-Cookie’.

If the user opens that file not using ‘Protected View’ on the sequence 1,

the session id is preserved on the sequence 3. The http request header

doesn’t contain ‘Pragma’=‘no-cache’.

I can’t find much documentation for Protected View, but there’s some indication that it may be fiddling with the context that the web request uses when you click on the link:

https://onmessages.wordpress.com/2015/01/19/a-security-problem-has-occurred-in-word/

This may be a security restriction to prevent malicious documents from including hyperlinks to third-party sites that rely on the user’s existing cookies to do XSS.

–Matt Jones

Thanks for your insight. I’ll check the detail of that page.

So there’s your problem. if the cookie header is not set then rails will think there is no existing session. As Matt says, this is probably a security thing.

Fred