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

As a repository admin, I would like to disable email confirmation for known domains #6915

Closed
RightInTwo opened this issue May 16, 2020 · 10 comments

Comments

@RightInTwo
Copy link
Contributor

RightInTwo commented May 16, 2020

For our own domain, we synchronize (custom sync, no Shib, no OIDC) the accounts in Dataverse with our institutional accounts. To still use the API to create these users, it would be great to have a switch in the json that says "this email address is valid" and therefore skip the confirmation mail (or at least use a different text for it - just a "welcome" instead a "please verify your email") or set the "email confirmed date" as another way to disable confirmation.

Are there any workarounds that make do with just the API? I'm thinking of just patching our installation and hard-coding the valid domain into authorization/AuthenticationServiceBean.java ->
createAuthenticatedUser(...) with
authenticatedUser.setEmailConfirmed(emailConfirmedNow); if the email address ends in our TLD.

"Welcome" emails would be sent separately.

Any ideas?

@donsizemore
Copy link
Contributor

related to #5663

@pdurbin
Copy link
Member

pdurbin commented May 18, 2020

If you're saying you'd like to add another field to the JSON at http://guides.dataverse.org/en/4.20/api/native-api.html#create-a-builtin-user I don't think that would be a huge deal. Here's what's there right now:

{
  "firstName": "Lisa",
  "lastName": "Simpson",
  "userName": "lsimpson",
  "affiliation": "Springfield",
  "position": "Student",
  "email": "lsimpson@mailinator.com"
}

Maybe something like this would be added:

  "emailConfirmed": true,

Changes would have to be made to the back end to support this, of course, but I don't think it would be a huge effort.

By the way, there are a couple methods in Admin.java that are used for testing (in ConfirmEmailIT.java):

  • startConfirmEmailProcess
  • getConfirmEmailToken

@scolapasta
Copy link
Contributor

What if this was an attribute of the authentication provider itself? In general, in would be true for shib and false for anything else, but @RightInTwo's installation could set it to true for builtinusers?

@RightInTwo
Copy link
Contributor Author

@scolapasta Hi Gustavo! There would need to be a way of defining which domains are trustworthy. Users from outside the institute would need to validate their addresses just as usual.

@scolapasta
Copy link
Contributor

Oh right, I misread and thought you meant all your built in users. But you're saying just your domain. Then I guess this would not work, because someone could just type in the domain that is trustworthy without an actual account (the whole reason for the confirmation in the first place).

@RightInTwo
Copy link
Contributor Author

RightInTwo commented May 19, 2020

@scolapasta True, thanks. Self-signup would need to be disallowed for that domain. That makes sense to do anyways, because we create an account for every user in that domain through the API and we can warn users about that in the UI if they try to sign up with an institutional address.

Posting an additional field in the json seems the way to go anyways:

"emailConfirmed": true,

...would be exactly what i was looking for. For more flexibility, one could also make "email confirmed date" available.

@pdurbin
Copy link
Member

pdurbin commented May 19, 2020

Oh, on the backend we store a date (probably a timestamp), not a boolean. I was thinking we'd just convert "true" to a date meaning "now".

One thing to keep in mind is that there are currently no consequences if your email address hasn't been confirmed. Right now it's just a timestamp that Dataverse keeps track of. If you're interested in restrictions for unconfirmed accounts, please see #3300.

@poikilotherm
Copy link
Contributor

poikilotherm commented May 28, 2020

Related to #6936
As Gustavo mentioned this might be nice to be attached to provider configuration, this is also related to #6694 et al.

@RightInTwo
Copy link
Contributor Author

For our purposes, #7033 is a sufficient fix. However, this functionality might still be of interest for the self-signup.

@pdurbin
Copy link
Member

pdurbin commented Jul 14, 2020

@RightInTwo if you're all set it probably makes sense to close this issue. You could always create a new issue down the road with further thoughts or requirements. Thanks for the pull request!

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

6 participants