Skip to content

Allow authentication using CERN/ORCID login #5

Open

Description

@GraemeWatt

If a HEPData account was created with CERN or ORCID authentication, a separate HEPData password needs to be set before the CLI upload feature can be used. Eventually, it might be useful for the CLI to allow login using CERN or ORCID authentication, depending on how complicated it is to implement.

Activity

  1. moved this to Todo in @HEPDataon Feb 3, 2022
  2. frgigr commented on Jul 15, 2022

    @frgigr

    Hello! Any news on this topic? Is there anyone working on it?
    It would be quite useful to be implemented, e.g. it will allow a complete integration in a Gitlab CI/CD, making things easier for many CERN people creating the HEPData submission tarball.
    Thanks in advance!

  3. GraemeWatt commented on Jul 15, 2022

    @GraemeWatt
    MemberAuthor

    No-one is working on this at the moment. Feel free to contribute. But it should already be possible to upload via GitLab CI/CD using an email address and local HEPData password (see e.g. this comment). For a HEPData account created with CERN/ORCID authentication, a local HEPData password can be set via https://www.hepdata.net/lost-password/ . Why do you need to log in with CERN authentication for complete integration in a GitLab CI/CD workflow?

  4. frgigr commented on Jul 15, 2022

    @frgigr

    Thanks for the reply! Yes, I know about the other option, but in (CERN) GitLab there's a specific variable holding your account password, so you don't need to set it explicitly in the repository settings. And it would be nice to avoid remembering another password, that's it XD

    Anyway, is it clear where the issue is? Is it in the package itself or somewhere else?

  5. GraemeWatt commented on Jul 15, 2022

    @GraemeWatt
    MemberAuthor

    Thanks for the explanation. I don't have much experience with CERN GitLab, but I can see that it would be useful to use CERN authentication if there's already a variable for the password. The main function to be modified would be cli_upload in the repository for the main web app. The upload function of hepdata-cli would also need to accept an additional argument specifying CERN/ORCID login rather than local HEPData login, then pass that argument to cli_upload. The difficult part is working out how to actually do the CERN/ORCID authentication inside cli_upload. For the web login we use invenio-oauthclient, but I'd need to investigate if that can also be used in cli_upload.

  6. GraemeWatt commented on Jul 18, 2022

    @GraemeWatt
    MemberAuthor

    I can't see how to use invenio-oauthclient for CERN/ORCID authentication inside cli_upload. Moreover, the purpose of OAuth is to grant third-party (HEPData) access without directly providing credentials (e.g. CERN/ORCID password) to the third party (HEPData). So I'm not sure if this issue even makes sense, but I'll leave it open for now in case anyone more knowledgable can provide details of a secure implementation of CERN/ORCID authentication for the hepdata-cli tool.

  7. kratsg commented on Oct 25, 2022

    @kratsg

    Thanks for the reply! Yes, I know about the other option, but in (CERN) GitLab there's a specific variable holding your account password, so you don't need to set it explicitly in the repository settings. And it would be nice to avoid remembering another password, that's it XD

    Hi, this isn't true. You would have to add it manually.

    can't see how to use invenio-oauthclient for CERN/ORCID authentication inside cli_upload. Moreover, the purpose of OAuth is to grant third-party (HEPData) access without directly providing credentials (e.g. CERN/ORCID password) to the third party (HEPData).

    The flow here is typically that you would receive a CERN OAuth token, and you can just go to CERN's authorization service to check to see if it's valid before doing anything more with the API (similar to how you might do it internally). I think it's overkill in this case, as you want to be the authorization/authentication service so if you provide OAuth tokens, then it's basically equivalent with an extra step.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requesthelp wantedExtra attention is needed

    Type

    No type

    Projects

    • Status
      To do

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions