View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001976||Xdebug||Step Debugging||public||2021-05-19 16:48||2021-06-16 23:25|
|Summary||0001976: XDEBUG_SESSION sameSite/expire setting|
|Description||Can we have a option for sameSite, so that we can set it to lax or something that the dev needs it to be for the project at hand? |
We have an issue with it being set as strict in our project. When doing a oAuth flow for login, the cookie does not get applied on the initial transfer back to our site after a login. The browser states that it ignored the cookie, because the source post was not from the same site. So we can not debug the first login page request with the oAuth info. This initial post back to the site lets us know if there was a problem with the login, apply tokens, etc...
Can we also have an option that allows us to set the timeout for the cookie?
Currently when debugging a long workflow, and not closing down the debug session in the IDE, the 1 hour limit kills the debug session and we must restart it.
Sorry if these are already options, and I am just not finding them.
|Tags||No tags attached.|
|Operating System||Windows 10|
||I am using Visual Studio 2019 v.16.9.5, PHP Tools for Visual Studio v.1.52.13352.2019, and Edge v.90.0.818.62|
You could do one of the following
set the cookie manually in browser or PHP. Then you choose the time and same site policy, as long as you dont have xdebug_start_session in GET / POST/ ENV it wont be overwritten
or set to start on every request
then you don't need the cookie
This is a feature request...
I didn't realize this was a forum... We're not looking for a hack workaround to add to code that is used only in development...
This is not a forum, indeed.
Is there actually a reason to have the "strict" cookies, and can Xdebug get away with just using "lax"?
Similarly, does it make sense that there is a limit of an hour for the cookie anyway?
The reason why I'm asking is, that I prefer as few settings as possible, so if I can get away with not adding settings, and just changing things, that I'd find preferable.
I don't see any reason why lax would not work as the default. Most likely being apart of development environment anyway, it's probably best for it to be lax to allow greater flexablity.
I think it would also be completely fine to have the cookie be set to expire on browser close.
|2021-05-19 16:48||johnwc||New Issue|
|2021-05-19 16:51||johnwc||Note Added: 0005882|
|2021-06-14 11:29||exussum||Note Added: 0005902|
|2021-06-14 16:17||johnwc||Note Added: 0005904|
|2021-06-16 18:59||derick||Assigned To||=> derick|
|2021-06-16 18:59||derick||Status||new => feedback|
|2021-06-16 18:59||derick||Note Added: 0005906|
|2021-06-16 23:25||johnwc||Note Added: 0005907|
|2021-06-16 23:25||johnwc||Status||feedback => assigned|