Hi Akshay, Please find the attached updated patch.
Thanks, Khushboo On Mon, Apr 26, 2021 at 12:42 PM Akshay Joshi <akshay.jo...@enterprisedb.com> wrote: > Hi Khushboo > > I have applied your patch and started testing it in different scenarios. > Following > are the GUI review comments: > > - Update the comments about Kerberos support for AUTHENTICATION_SOURCES > in config.py. > > Done. > > - You will have to create a migration file again. Getting "Error: > Multiple head revisions are present for given argument" > > Done. > > - Increase the height of the server dialog as after adding "Kerberos > Authentication?" switch Connection tab showing scroll bars. > > This is the default behaviour of all the dialogues, for example: Table Advanced tab > > - Desktop/Server mode Getting No such file or directory: > '/var/lib/pgadmin/krbccache'. KERBEROS_CCACHE_DIR should only be > created in Server Mode and AUTHENTICATION_SOURCES is 'kerberos'. > > Done > > - Server Dialog "Kerberos Authentication?" switch control should be > enabled only in Server Mode and AUTHENTICATION_SOURCES is 'kerberos'. > > Done > > - "Kerberos Authentication?" switch should be disabled when the server > is connected. > > Even if the user changes the setting when the server is connected, the effect will take place only on reconnection, so I think we can leave it as it is. > > - In Desktop mode AUTHENTICATION_SOURCES must be '*internal*' doesn't > matter what mode is provided in *config.py *or* config_local.py*. In > fact, we should create a flag '*authentication_mode*' which will be > set after the valid authentication source has been detected/connected. *For > example,* the user has provided AUTHENTICATION_SOURCES = ['kerberos', > 'internal'], it is unable to connect using kerberos and then the user has > provided a valid email and password so we will set ' > *authentication_mode*' to 'internal' and the rest of the logic will be > based on that flag. > > This was already taken care of. > > - > > > - Connect to any database server and check backend logs following > error is visible: > - KeyError: 'KRB5CCNAME' *Solution*: It should not call > "kerberos_validate_ticket()" function until AUTHENTICATION_SOURCES is > 'kerberos' and Server Mode is true. > > Fixed. > *AUTHENTICATION_SOURCES = ['kerberos']:* > > - Kerberos is not set up: Open pgAdmin page, enter email and password > two message box popped up one with valid Kerberos error and the second one > with "None" as a string. > > Fixed > > - Similarly, if AUTHENTICATION_SOURCES = ['kerberos', 'internal'] and > it is failed to connect using kerberos, then provide an email, and the > wrong password two message boxes popped up one with Kerberos error and > another with Password error. > > Somehow, I couldn't find the fix for this issue, for now we can ignore this as this will not affect the login process. > > - In the User Management dialog 'kerberos' should not be visible in > the authentication source dropdown. As there is no point creating kerberos > user from there. > > We have provided an option to add manual users for Kerberos also the same as LDAP. > > - Add local server(without kerberos) to the browser tree, set > "Kerberos Authentication?" to True, try to connect by providing the > password it always returns "fe_sendauth: no password supplied" error. If > possible can we identify and change the error message? > > Fixed > > - Add database server where kerberos authentication is ON, make > changes in pg_hba.conf with the wrong user name, then try to connect to the > database server. The server tries to connect and the spinner is visible and > never stops. It should raise a proper error message. There are some other > scenarios where entries in pg_hba.conf is wrong. > > Fixed > > - *Suggestion 1*: As per current implementation even if "Kerberos > Authentication?" is set to false the user can connect to the database > server by providing any password or blank password. It is difficult for the > user to identify it is connected using GSSAPI. I would suggest providing > the control in the properties dialog which tells the database server is > connected using GSSAPI. > > I have removed the old implementation in which the user was able to connect the PostgresQL even if a user has not selected "Kerberos Authentication" but we have a valid kerberos ticket and pg_hba is configured to support it. So, now users can get the idea about the connection through The "Kerberos authentication" flag displayed on the properties tab. > > - *Suggestion 2*: If it is possible to detect that the database server > is connected using Kerberos then we should disable the 'Username' control > as for Kerberos both the users (pgadmin user and database user ) must be > the same. > > > *Note:- *pgAdmin on OSX not working with Kerberos authentication. Failed > with error "Your GSSAPI implementation does not have support for > manipulating credential stores directly" Need to document this behavior. > Thanks, khushboo > > *Code review still remains, which I'll be started after the above fixes.* > > On Wed, Apr 14, 2021 at 2:06 PM Khushboo Vashi < > khushboo.va...@enterprisedb.com> wrote: > >> Hi, >> >> Please find the attached patch with some minor improvements. >> >> Thanks, >> Khushboo >> >> On Wed, Apr 7, 2021 at 11:50 PM Khushboo Vashi < >> khushboo.va...@enterprisedb.com> wrote: >> >>> Hi, >>> >>> Please find the attached patch for RM 6158: Support Kerberos >>> Authentication - Phase 2. >>> This patch includes the support for logging into PostgreSQL servers with >>> Kerberos authentication. >>> >>> Thanks, >>> Khushboo >>> >>> > > -- > *Thanks & Regards* > *Akshay Joshi* > *pgAdmin Hacker | Principal Software Architect* > *EDB Postgres <http://edbpostgres.com>* > > *Mobile: +91 976-788-8246* >
RM_6158_v2.patch
Description: Binary data
