session renewed on cross-domain preflight requests

[migliori]

Hello,

Thanks for your great work.
I'm using your session manager on an android/ios application and got a problem caused by the cross-domain requests.

The browser sends a preflight request with OPTIONS method to allow or reject the request depending on CORS.
I don't know exactly what happens, but if the request goes to the session it randomly breaks the script.
Preflight requests are not supposed to return cookies, so I added this code at the beginning of my API index to intercept the OPTIONS requests and prevent the script to go further:

// & break to avoid session issues
if ($_SERVER['REQUEST_METHOD'] == 'OPTIONS') {
    exit;
}

It solved my issue, but maybe you have a better way to avoid this problem?
And maybe this report could help others users ...

[bryanjhv]

Preflight requests are not supposed to return cookies

Do you have any link (from a trustable source) that documents this?

If that's the case, I'll find a way to incorporate your conditional into this library's code.
If not, I could add some tips for handling that case, along the lines of conditionally adding the middleware.

[migliori]

Do you have any link (from a trustable source) that documents this?

https://fetch.spec.whatwg.org/#cors-preflight-fetch
"6. If one of request’s header list’s names is a CORS non-wildcard request-header name and is not a byte-case-insensitive match for an item in headerNames, then return a network error."

Cookies belongs to the forbidden header name list

I found these references from https://stackoverflow.com/questions/41760128/cookies-not-sent-on-options-requests

[bryanjhv]

Ok, there are some things to notice here:

1. window.fetch lives in the frontend and this slim-session in the backend.
2. Your links go to window.fetch specification. CORS is not specific to fetch (XHR follows the same rules).
3. There are two different concepts: requests and responses (the spec shows them as italic text).
4. Your docs say that: you shouldn't send Set-Cookie when doing your request (XHR doesn't allow it either).
5. This package receives requests and provides responses (sort of because it's just a middleware).

Nonetheless, I understand that you're having a problem with your client-side application.
But I don't see where the problem you're facing resides without some sample code to test.
(so I can be sure it's my entire fault, and it might affect other users as well)

PS: I'll try to dig a little perhaps I'm wrong. But some sample code would be helpful.

[migliori]

I appreciate you taking the time to dig into this, thanks.
I'm an experienced php developer, but a bit new on applications (VueJs, Capacitor, ...)
So probably not enough specialist in CORS issues.
I ended up working around the problem because the sessions were too difficult to manage (a website is coupled to the application, the origins of the requests are different depending on the situation (localhost, website, capacitor, IOS application, Android application)

So I exchange data without php session, using an encryption / decryption that allows me to secure the exchanges.

Sorry, I couldn't provide you with a code example, but making an exit on the options requests had solved this problem for me.

Translated with www.DeepL.com/Translator (free version)