IdP url opened twice

Driver version

2.0.882

Redshift version

Not a Redshift problem

Client Operating System

MacOS Big Sur

Python version

3.7.7

Table schema

Not a Redshift problem

Problem description

Connecting to a Redshift cluster with credentials being provided by IdP (Okta in this case) results in Okta login_url page being opened twice if I have already signed in previously. To make it a bit more confusing, when redirected back to http://localhost:7890/redshift/ the page shows “This site can’t be reached”. Connection is established after that with no issues and I can execute the query.

I’ve also setup a connection in DBeaver using the same IdP and the same login_url. In this case the login_url page is opened only once and a proper message saying Thank you for using Amazon Redshift! You can now close this window. is shown.

1. Expected behaviour: IdP login_url is opened once. After successful login and redirect to http://localhost:7890/redshift/, the page shows the same Thank you for using Amazon Redshift! You can now close this window.

2. Actual behaviour: IdP login_url is opened twice. When redirected to http://localhost:7890/redshift/ it shows “This site can’t be reached”

3. Error message/stack trace: No errors other than “This site can’t be reached” in the browser

4. Any other details that can be helpful:

Python Driver trace logs

None

Reproduction code

import redshift_connector


conn = redshift_connector.connect(
    iam=True,
    ssl=True,
    host="REDSHIFT_ENDPOINT",
    port=5439,
    database="DB_NAME",
    db_user="IDP_USERNAME",
    region="AWS_REGION",
    cluster_identifier="CLUSTER_NAME",
    login_url="IDP_LOGIN_URL",
    credentials_provider="BrowserSamlCredentialsProvider",
    user="",
    password=""
)

cursor: redshift_connector.Cursor = conn.cursor()
cursor.execute("select current_user")

result = cursor.fetchone()
print(result)

[Brooke-white]

Hi @ivica-k ,

Thank you for taking the time to dive into this issue. I am happy we have been able to determine a root cause for this issue…this also explains why I was unable to reproduce as my timezone is PST 😃

The team would be happy to have your contribution for this issue – the edit you provided looks good!

Back to the “Connection Refused” screen in the browser following authentication, the team has merged a fix for this and it will be included in our next release, which is scheduled for July 19.

[Brooke-white]

Hey @ivica-k ,

Every CredentialsHolder object has an expiration. You can think of the CredentialsHolder class as wrapper around the temporary credentials retrieved when using IAM authentication.

What should happen with self.expiration in this case? Should it be changed based on the local timezone? Or should I maybe add self.expiration_local and change self.expiration to self.expiration_utc ?

Let’s chat more in the PR, but I think we can keep expiration as is and do a conversion to the local timezone within is_expired(). We should probably add a logging.debug statement within this method which outputs the original UTC datetime and the localized one. This could be helpful to future debugging surrounding this area of the code base 😃

Thanks again for diving into this issue, the team really appreciates your help!