Help / Feature Request - Provide pre-authenticated access/refresh tokens to access API functionality

[bekindpleaserewind]

Is there anyway to provide a pre-authenticated access/refresh token that has been obtained via outside means (i.e. frontend web). I have no need for authenticating through the application, or providing a username/password. I'd like to be able to use the entire API that is exposed to a user token that can be passed in as an argument for outside authentication. I think this would be extremely beneficial to many people. Especially if the threading safe rate limiting type functionality is working with it.

If this is possible to do now, could some instructions be provided? If this is not possible, could this put converted to a feature request?

Thanks!

[bekindpleaserewind]

I looked through the code a bit and I think what is confusing about this is the requirement of a username and password in the "user" argument to the API class.

If I'm reading through the code correctly, it looks like if no matter what you need to specify "email_or_username" and "password" (can't be an empty string or missing entirely). Then in token.py it runs _authorization_flow() which tries to import playwright, which fails on the basic ebay_rest installation.

Once that has failed, it will take the refresh_token and refresh_token_expiry passed to API and utilize that.

Is that a correct analysis of how this works? If so, it may make sense to make email_or_username and password optional arguments when only passing a refresh_token and refresh_token_expiry.

[matecsaj]

It has been years since I worked on that part of the library, so I can't answer your question from memory, but a quick test comes to mind.

Please try using dummy values to sneak past the existence checks.

email_or_username = '[email protected]'
password = 'Testing123?'
refresh_token = obtained by your outside means
refresh_token_expire = obtained by your outside means

Does the API call you do work just fine when the first two values here are incorrect?

[bekindpleaserewind]

@matecsaj Yep, dummy values seem to work. Can you confirm if this will actually generate a failed login request? I don't think it should reading through the code but was hoping to get a second set of eyes.

[matecsaj]

Thanks for running that test. I agree with your code survey conclusions and have no reservations concerning rate-limiting or threading.

I would like to elaborate on your proposed change, which aims to catch errors that a programmer might make as early as possible.

User-token related input values:
Set A = (email_or_username, password)
Set B = (refresh_token, refresh_token_expire)

Error when only one element of a set is blank.
Error when both sets have all blank elements.

Do you think this would work for your needs and others?

[bekindpleaserewind]

@matecsaj I think the following conditions may make sense. Comments are very much welcomed.

1. Make Set A (email_or_username, password) optional.
2. If Set A is blank, require Set B.
3. Still allow A and B to be filled out together.
4. Update documentation to explain the workflow / how to use refresh tokens only (no username/password)

[matecsaj]

Looks good. You are welcome to provide a PR, or I will make the change when I have free time.

In the interim, please use the "dummy values" work around.

Thanks for identifying an opportunity for improvement and collaborating to find the best solution.

[matecsaj]

In preparation, I refactored the API class into two major parts. End users shouldn’t notice any difference, but let’s gauge the reaction to the next release before moving forward.

b86d111