Hi
On Tue, Dec 1, 2020 at 5:51 PM Rahul Shirsat <rahul.shir...@enterprisedb.com>
wrote:
> Hi Dave,
>
> Could you please add below FAQ point for SameSite Safari issue:
>
> Question :
> When I set new tab settings for query tool or schema-diff, I get
> "Connection to server lost" or "CSRF tokens do not match" on Safari
> versions >= 12
>
> Answer:
> <p>This has been seen mostly on Safari browser versions >= 12. It's
> reported that from v12 of CFNetwork/Safari/Webkit erroneously handle
> "Samesite=none" as the equivalent of "Samesite=strict". It means, Safari
> recognizes the SameSite option starting with version 12, but their
> implementation has a bug: It interprets invalid values as if
> SameSite=Strict had been specified, and for it only Strict and Lax are
> valid values, as the older specification did not yet specify None</p>
>
> <p>To solve this issue, we need to override the SameSite security
> settings, for this, create a file called config_system.py in the web/
> directory of the installation, alongside the existing config.py. This file
> can be used to override any of the settings in config.py (which shouldn't
> be edited). The config_system.py should have the below code:</p>
>
We could certainly add something like that, though, config_system.py
doesn't go alongside config.py so that part of the text needs fixing.
>
> <pre>
> import sys
>
> # Targeting only macOS
> if sys.platform.startswith('darwin'):
> SESSION_COOKIE_SAMESITE = None
> SESSION_COOKIE_SECURE = True
> </pre>
>
> Do suggest or add any points if I am missing them.
>
And that is not going to work in Server mode, only Desktop.
>
> Also, let me know once this is done, So that I will close the ticket.
>
> --
> *Rahul Shirsat*
> Senior Software Engineer | EnterpriseDB Corporation.
>
> On Mon, Nov 30, 2020 at 7:30 PM Rahul Shirsat <
> rahul.shir...@enterprisedb.com> wrote:
>
>> This was the part of our internal quality testing, where it got
>> encountered. Currently, none of the users have complained about this on
>> their specific browser versions.
>>
>> On Mon, Nov 30, 2020 at 5:12 PM Dave Page <dp...@pgadmin.org> wrote:
>>
>>> Hi
>>>
>>> On Mon, Nov 30, 2020 at 7:12 AM Rahul Shirsat <
>>> rahul.shir...@enterprisedb.com> wrote:
>>>
>>>> Dave,
>>>>
>>>> There are issues discussed on Apple forums, check this out:
>>>>
>>>> https://developer.apple.com/forums/thread/129064 - The latest comment
>>>> by the user here is one month ago, meaning the issue is still not fixed
>>>> yet.
>>>> https://developer.apple.com/forums/thread/658688 - Users facing this
>>>> issue in v13.x
>>>>
>>>> Even webkit has confirmed about this issue :
>>>> https://bugs.webkit.org/show_bug.cgi?id=198181 - Users facing this
>>>> issue in v12.x
>>>>
>>>
>>> In that case, I think the answer (for now at least) is an FAQ,
>>> referencing those issues and explaining how to resolve the issue using
>>> config_system.py or by using a different browser.
>>>
>>> Have we actually seen this issue in wild?
>>>
>>>
>>>
>>>>
>>>> On Thu, Nov 26, 2020 at 6:57 PM Dave Page <dp...@pgadmin.org> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> On Wed, Nov 25, 2020 at 10:37 AM Rahul Shirsat <
>>>>> rahul.shir...@enterprisedb.com> wrote:
>>>>>
>>>>>> Hi Dave,
>>>>>>
>>>>>> Due to SameSite security issues in Safari Browser, some of the
>>>>>> pgadmin4 functionality isn't working (mostly the new tab functionality).
>>>>>>
>>>>>> The affected Safari Browser versions (marked in red) currently tested
>>>>>> upon are:
>>>>>>
>>>>>> 1. v11.1.2
>>>>>> 2. v12.1
>>>>>> 3. v12.1.1
>>>>>> 4. 13.1
>>>>>> 5. 14.0.1
>>>>>>
>>>>>> Since v12, Safari have done some security fixes, due to which this
>>>>>> issue has occurred. Strangely, the issue is not reproducible on v13, but
>>>>>> reproducible on its successor i.e. v14
>>>>>>
>>>>>> Possible solutions could be:
>>>>>>
>>>>>> 1. Reporting this to Safari & raising an RM for tracking purposes.
>>>>>> 2. Suggesting Safari users to make below changes in config.py or
>>>>>> config_distro for the work around:
>>>>>>
>>>>>> *SESSION_COOKIE_SAMESITE = None*
>>>>>>
>>>>>> *SESSION_COOKIE_SECURE = True*
>>>>>> (As we aren't going through any cross-site cookie transfer, this can
>>>>>> be a handy option - but still risky..)
>>>>>>
>>>>>> I would suggest going with the 1st option or combination of both, but
>>>>>> with caution.
>>>>>>
>>>>>
>>>>> Others must have come across this issue already. Is it a known bug,
>>>>> documented somewhere (ideally on apple.com)?
>>>>>
>>>>> --
>>>>> Dave Page
>>>>> Blog: http://pgsnake.blogspot.com
>>>>> Twitter: @pgsnake
>>>>>
>>>>> EDB: http://www.enterprisedb.com
>>>>>
>>>>>
>>>>
>>>> --
>>>> *Rahul Shirsat*
>>>> Software Engineer | EnterpriseDB Corporation.
>>>>
>>>
>>>
>>> --
>>> Dave Page
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>> EDB: http://www.enterprisedb.com
>>>
>>>
>>
>> --
>> *Rahul Shirsat*
>> Software Engineer | EnterpriseDB Corporation.
>>
>
>
> --
> *Rahul Shirsat*
> Software Engineer | EnterpriseDB Corporation.
>
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EDB: http://www.enterprisedb.com
