Re: SameSite issues in Safari Browser (reference #RM5975)

Hi

Please check: https://www.pgadmin.org/faq/#13

On Thu, Dec 3, 2020 at 8:54 AM Rahul Shirsat <rahul(dot)shirsat(at)enterprisedb(dot)com>
wrote:

> Dave,
>
> Please find below corrected faq details.
>
> Category : Troubleshooting
>
> 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 (for location to
> create the file, refer <a href="
> https://www.pgadmin.org/docs/pgadmin4/development/config_py.html">The
> config.py file</a>). 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>
>
> <pre>
> SESSION_COOKIE_SAMESITE = None
> SESSION_COOKIE_SECURE = True
> </pre>
> <p><i>Note that these changes are not recommended, and we highly recommend
> users to use a different browser until the issue gets resolved from
> Apple.</i>
>
> Removed the OS specific condition to make it generic for all distributions.
> Added a warning note at the last of the faq.
>
> On Wed, Dec 2, 2020 at 4:33 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
>> Hi
>>
>> On Tue, Dec 1, 2020 at 5:51 PM Rahul Shirsat <
>> rahul(dot)shirsat(at)enterprisedb(dot)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(dot)shirsat(at)enterprisedb(dot)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 <dpage(at)pgadmin(dot)org> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> On Mon, Nov 30, 2020 at 7:12 AM Rahul Shirsat <
>>>>> rahul(dot)shirsat(at)enterprisedb(dot)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 <dpage(at)pgadmin(dot)org> wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> On Wed, Nov 25, 2020 at 10:37 AM Rahul Shirsat <
>>>>>>> rahul(dot)shirsat(at)enterprisedb(dot)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
>>
>>
>
> --
> *Rahul Shirsat*
> Software Engineer | EnterpriseDB Corporation.
>

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: http://www.enterprisedb.com