Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Normalize namespace doesn't work for EGI Checkin users #60

Open
JanssenBrm opened this issue Jun 20, 2024 · 3 comments
Open

Normalize namespace doesn't work for EGI Checkin users #60

JanssenBrm opened this issue Jun 20, 2024 · 3 comments

Comments

@JanssenBrm
Copy link
Contributor

We noticed a strange behaviour in the openEO Web Editor where a UDP wasn't correctly loaded into the wizard. It mentions Process not found: https://editor.openeo.org/?server=https://openeo.vito.be&namespaces=https://openeo.vito.be/openeo/processes/u:63d26122aec1fc5ae2c16a045570e4d90e89fb3a51081c0d9d6047c270f72940@egi.eu/CORSAcompression&wizard=UDP&wizard~process=CORSAcompression@https://openeo.vito.be/openeo/processes/u:63d26122aec1fc5ae2c16a045570e4d90e89fb3a51081c0d9d6047c270f72940@egi.eu/CORSAcompression

After some debugging of the requests, we noticed that the web editor is loading in the processes of the namespace through the following URL: https://openeo.vito.be/openeo/1.2/processes/u:63d26122aec1fc5ae2c16a045570e4d90e89fb3a51081c0d9d6047c270f72940. However, this URL is missing the @egi.eu part, resulting in an empty array of processes.

A short debug session leads us to the function that is used to normalize the namespace naming:

const matches = namespace.match( /^https?:\/\/.*\/processes\/(@?[\w\-.~:]+)\/?/i);
. It appears that regex is ignoring the part that is behind @ sign. We believe that this could be causing the issue.

I'm happy to open a PR, but I wanted to create this issue first to check if this could be causing the issue and assess the impact of it.

@JanssenBrm
Copy link
Contributor Author

Tagging @Pratichhya as she was experiencing the initial issue.

@JanssenBrm
Copy link
Contributor Author

Maybe it also has an impact on the changes requested in Open-EO/openeo-api#515

@m-mohr
Copy link
Member

m-mohr commented Jun 20, 2024

This is all not yet part of the official API, so the JS client implementation follows the only thing we have - Open-EO/openeo-api#348 - which defines the pattern as implemented here and as such doesn't allow @ in this place. Before I merge any more unofficial extensions to the clients, I'd like to conclude on the API extension first so that we can implement the finally agreed solution.

I don't think this has an impact on Open-EO/openeo-api#515.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants