[BUG] No warning for incorrect login

[mdtanker]

Is this issue already tracked somewhere, or is this a new report?

• I've reviewed existing issues and couldn't find a duplicate for this problem.

Current Behavior

Thanks for the work with earthaccess! I've been using it for a while with no issues, however, I'm setting up a new computer, and I noticed when I use

earthaccess.login()

and I'm prompted for my username and password, if I enter an incorrect value, I don't receive any error messages. I would expect an error for logging in failed. This seems to happen for both interactive and environment strategies, I haven't tried with the netrc strategy.

Expected Behavior

When logging in fails in earthaccess.login(), an error message is raised telling the users the login failed.

Steps To Reproduce

import earthaccess

earthaccess.login()

-> manually type in username and password

Environment

- OS: Linux (Fedora)
- Python: 3.12.7

- OS: Windows 10
- Python: 3.11.11

Additional Context

I'm happy to try and open a PR if this is something you want implemented.

[asteiker]

@mdtanker Thank you for reporting this. I'm surprised by this behavior and agree this should be throwing an error. I did a very quick test running python on my Mac terminal and this was returned when I entered an invalid username and password:

Authentication with Earthdata Login failed with: {"error":"invalid_credentials","error_description":"Invalid user credentials"} Warning: the current session is not authenticated with NASA
I'll do some other testing in a Jupyter notebook and confirm that I'm comparing apples to apples in terms of versions. Regardless it would be fantastic if you contributed a PR to address this! Please let us know how we can help facilitate or provide additional guidance. Here is our development guide for reference: https://earthaccess.readthedocs.io/en/latest/contributing/development/

[mfisher87]

If you'd like to co-work or chat, we have a bi-weekly hack day coming up tomorrow: https://earthaccess.readthedocs.io/en/latest/contributing/our-meet-ups/

Ping me your email on linkedin if you'd like a calendar invite!

[mdtanker]

@mfisher87 could you send the invite? I just messaged you on Linkedin, thanks!

[mfisher87]

Hey Matt, just saw your message now; sent the zoom and calendar invite! The meeting is 30 minutes in, but all are welcome to drop in and drop out. Someone will be in the lobby to greet you! 1.5 hours remaining :)

[mdtanker]

After a little digging I think this is a logging issue. The logging call in this line is info instead of error:

logger.info(
    f"Authentication with Earthdata Login failed with:\n{token_resp.text}"
)

Happy to fix this in a PR.

Is there a reason an error is not raised (instead of just a logged message) when authentication fails? Is it because you want earthaccess.login() to automatically try the next strategy if the first one fails, instead of exiting?

[mfisher87]

earthaccess will try multiple strategies, but it seems to me that it's unintentional that it would continue after an actual login failure. After finding no stored credentials, it makes sense to continue and try another strategy. But if a login fails, that needs to be fixed and earthaccess should, IMO, exit with an error. I think it would be useful to write a flowchart of earthaccess' intended login behavior when a strategy isn't specified, including when credentials are rejected and when credentials are not found. That can flesh out this doc page: https://earthaccess.readthedocs.io/en/latest/user_guide/authenticate/

This doc page (https://earthaccess.readthedocs.io/en/latest/howto/authenticate/) does document:

If a strategy is not specified, environment variables will be used first, then a .netrc (if found, see below), and finally a user's input.

But I think we could be more specific with a flowchart in addition to a more detailed text description.

[mfisher87]

cc @betolink ☝️

[betolink]

Sorry I'm just looking at this (I'm at AGU all week). Agree with @mfisher87 if none of the strategies work we should throw an exception. Maybe this can be another item for tomorrow's hack day https://lu.ma/8mj6f3qn?tk=X2HwYD

A little tangential, we used to print some of these things instead of logging them, would it be useful to bring some print() statements back? e.g. when we search for data we used to print how many granules we found. I have the feeling that most users (including myself) don't look at the logs in Jupyterlab too often. Although, with the current linting configuration print() statements are not allowed, what do you guys think? @jhkennedy @chuckwondo @asteiker

[mfisher87]

Sorry I'm just looking at this (I'm at AGU all week). Agree with @mfisher87 if none of the strategies work we should throw an exception. Maybe this can be another item for tomorrow's hack day lu.ma/8mj6f3qn?tk=X2HwYD

Will there be a zoom?

[betolink]

Great question, I think this one will be mostly in-person, is that right @maxrjones?

[maxrjones]

Great question, I think this one will be mostly in-person, is that right @maxrjones?

Yes, I'm sorry that it's in-person only because the space isn't set up to support virtual participation well.

[mfisher87]

Understood, thanks for considering :)