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

[RightInTwo]

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]

related to #5663

[pdurbin]

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]

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]

@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]

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]

@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]

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]

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]

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

[pdurbin]

@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!