Login Error


since yesterday we sometimes have trouble during the login. The first try of the day works fine, but subsequent logins using the following code give an error message:

# change to login with your credentials
con = openeo::connect("https://openeo.cloud")
    login_type = "oidc"
    , provider = "egi"
    , config = list(
        client_id = "<id>"
        , secret = "<secret>"
#createTcpServer: address already in use
#Login failed. Reason: Failed to create server<OpenEOClient>

EGI shows multiple active access and refresh tokens. Interestingly, it has also created a second application for openEO Platform R-client in the approved services list.

Any idea on what caused the error and on why it only happens sometimes? Thanks as always!

thanks for the report. It sounds like the server that is started for authentication is not correctly shut down after authentication and then the port is blocked on subsequent executions. Are there multiple instances of R(Studio) or the openEO R Client running? Which version/branch of the R client are you using?


Thanks for looking into this. There are multiple running instances of RStudio, but only one of them is using the R Client.
We are currently using this version of the develop branch: fixed setting token expiry time on refreshing (#101) · Open-EO/openeo-r-client@7f10b61 · GitHub


is any of the other RStudio instances also running httr and is using the OAuth App with the standard redirect URL or more general, do you test on your local machine or on a remote RStudio Server? For the authentication procedure the client spawns via httr a temporary webservice which is going to receive the access_token. It listens for the redirect at the standard port 1410.

Lately, I have started to overhaul the authentication procedure by switching from httr to httr2, which allows us to provide the device code + pkce authentication flow, where we can skip the whole spawning of the webservice. That will make things easier.


all instances were on local machine, no httr or the OAuth App was used elsewhere.

We sometimes are accessing the back-end from different local machines and/or our AWS instance at the same time though, could this in theory present an issue? And if yes, what would be the best way to deal with it?