4

I'm developing an app that logs into a HTTPS website. After authentication, the website sends a final cookie that is marked as 'Secure'.

The app works when I use defaultSessionConfiguration() for NSURLSession().

When I change one line in the app to use the backgroundSessionConfigurationWithIdentifier() then I can't proceed past the authentication stage. I do get a webpage showing that I am authenticated but subsequent requests return the login page.

It appears that the "authentication successful cookie" is not present in the shared cookie storage.

This cookie is the only cookie that the website marks as "Secure". Note that this HTTPS website does all it transactions via HTTPS.

TL;DR What does the NSURLSession background session do differently from the default session to lose a Secure cookie??

EDIT: I've done some more work.

When NSURLSession redirects using the backgroundSessionConfiguration it appears to ignore cookies that were sent in the Header of the redirect? (I think the cookie being "Secure" may not be critical.)

The redirect works correctly when the defaultSessionConfiguration is specified.

andymc
  • 51
  • 7
  • The default session configuration uses a persistent disk-based cache (except when the result is downloaded to a file) and **stores credentials in the user’s keychain.** – Vin Mar 29 '16 at 05:14
  • Sorry. I should have mentioned this is an **iOS app**. Therefore cookies are stored in the sharedStorage for the app only. – andymc Mar 29 '16 at 05:20

1 Answers1

0

It turns out that this is a known bug. Apple r. 16,852,027.

The backgroundSession is known to ignore new cookies on redirect. The solution is to use a defaultSession to get the cookies and then continue using backgroundSession.

See Apple Developer Forum post

andymc
  • 51
  • 7