BuiltinUsers.Key

61 views
Skip to first unread message

Jamie Jamison

unread,
May 9, 2019, 5:05:26 PM5/9/19
to Dataverse Users Community
Is the BuiltinUsers.Key the api key or is this a different key I create?

For dataverse.ucla.edu users come in via Shibboleth, other authentications have been blocked. But I wanted to be able to create a local/builtin account from the api for exceptions such as visiting researcher.


Thank you,

Jamie

Philip Durbin

unread,
May 9, 2019, 7:01:28 PM5/9/19
to dataverse...@googlegroups.com
Hi Jamie,

I'm glad you wrote because I've been meaning to follow up with you on your other user-related questions on Tuesday's community call. I hope you find the additions I made to the notes after the call helpful: https://groups.google.com/d/msg/dataverse-community/op753PRmoUY/mm7GAGoaAgAJ

I guess my first question is why you want to use the API to create the user? Why not use the GUI and sign up with an email address you control (from Yahoo or whatever) and then change the email address to the visiting researcher afterwards? Are you expecting a log of visiting researchers leading you to want to automate this process? Or is it that you don't want the "Sign Up" link to appear? If so, the API is for you. :)

Yes, "BuiltinUsers.Key" is different than any API token that a user might have. The terminology is confusing. For developers the "BuiltinUsers.Key" is "burrito" but for production installations the burrito is deleted or eaten or whatever[1]. So you have to add "taco" or something[2], like this:



I hope this helps! Please keep the questions coming. :)

Phil


--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-commu...@googlegroups.com.
To post to this group, send email to dataverse...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/1e9928ee-871a-4fb9-820d-ba178881e747%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--

Jamie Jamison

unread,
May 9, 2019, 8:29:25 PM5/9/19
to Dataverse Users Community
Phil,

Thank you again.  The notes were very helpful. I'm working my way through the list of what needs to be done.  I'd say I'm doing the easiest to hardest but after surviving my upgrade of postgresql everything seems easier by comparison.

Why we decided to only add local users through the API is so the only time someone can create a dataverse is when they login - even for the first time - though shibboleth.  Most of the time we are limiting to UCLA affiliated but creating a local account for the exceptions.  

I may be wrong here but I thought that if the GUI is available then anyone can create an account, UCLA or not.  They do have to accept the terms but I've noticed no one seems to read what they click on.

Jamie




On Thursday, May 9, 2019 at 4:01:28 PM UTC-7, Philip Durbin wrote:
Hi Jamie,

I'm glad you wrote because I've been meaning to follow up with you on your other user-related questions on Tuesday's community call. I hope you find the additions I made to the notes after the call helpful: https://groups.google.com/d/msg/dataverse-community/op753PRmoUY/mm7GAGoaAgAJ

I guess my first question is why you want to use the API to create the user? Why not use the GUI and sign up with an email address you control (from Yahoo or whatever) and then change the email address to the visiting researcher afterwards? Are you expecting a log of visiting researchers leading you to want to automate this process? Or is it that you don't want the "Sign Up" link to appear? If so, the API is for you. :)

Yes, "BuiltinUsers.Key" is different than any API token that a user might have. The terminology is confusing. For developers the "BuiltinUsers.Key" is "burrito" but for production installations the burrito is deleted or eaten or whatever[1]. So you have to add "taco" or something[2], like this:



I hope this helps! Please keep the questions coming. :)

Phil


On Thu, May 9, 2019 at 5:05 PM Jamie Jamison <jam...@g.ucla.edu> wrote:
Is the BuiltinUsers.Key the api key or is this a different key I create?

For dataverse.ucla.edu users come in via Shibboleth, other authentications have been blocked. But I wanted to be able to create a local/builtin account from the api for exceptions such as visiting researcher.


Thank you,

Jamie

--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-community+unsub...@googlegroups.com.

Sherry Lake

unread,
May 10, 2019, 9:25:09 AM5/10/19
to dataverse...@googlegroups.com
Hi Jamie,

There is a setting to turn off the GUI -create-an-account.

It's the 
:AllowSignUp is set to “false” per the Configuration section to prevent users from creating local accounts via the web interface. 

UVa has this set to "false" so the ONLY way to create an account (and thus log in) is going through Shib - and we only have UVa as a choice in our "institution list". We have an "other option - username/email" that is ONLY used for the builtIn "dataverseAdmin" account. There is no "sign-up link".


Texas Data Library is similar, only select Texas institutions show up in the Shib pull-down list, but they do allow google account users (non-Texas) to create an account, but those users have NO publish (add dataset or dataverse) permissions until an admin sets it up. There is no GUI login.

Hope this helps.
Sherry Lake, UVa Dataverse - LibraData


On Thu, May 9, 2019 at 8:29 PM Jamie Jamison <jam...@g.ucla.edu> wrote:
Phil,

Thank you again.  The notes were very helpful. I'm working my way through the list of what needs to be done.  I'd say I'm doing the easiest to hardest but after surviving my upgrade of postgresql everything seems easier by comparison.

Why we decided to only add local users through the API is so the only time someone can create a dataverse is when they login - even for the first time - though shibboleth.  Most of the time we are limiting to UCLA affiliated but creating a local account for the exceptions.  

I may be wrong here but I thought that if the GUI is available then anyone can create an account, UCLA or not.  They do have to accept the terms but I've noticed no one seems to read what they click on.

Jamie




On Thursday, May 9, 2019 at 4:01:28 PM UTC-7, Philip Durbin wrote:
Hi Jamie,

I'm glad you wrote because I've been meaning to follow up with you on your other user-related questions on Tuesday's community call. I hope you find the additions I made to the notes after the call helpful: https://groups.google.com/d/msg/dataverse-community/op753PRmoUY/mm7GAGoaAgAJ

I guess my first question is why you want to use the API to create the user? Why not use the GUI and sign up with an email address you control (from Yahoo or whatever) and then change the email address to the visiting researcher afterwards? Are you expecting a log of visiting researchers leading you to want to automate this process? Or is it that you don't want the "Sign Up" link to appear? If so, the API is for you. :)

Yes, "BuiltinUsers.Key" is different than any API token that a user might have. The terminology is confusing. For developers the "BuiltinUsers.Key" is "burrito" but for production installations the burrito is deleted or eaten or whatever[1]. So you have to add "taco" or something[2], like this:



I hope this helps! Please keep the questions coming. :)

Phil


On Thu, May 9, 2019 at 5:05 PM Jamie Jamison <jam...@g.ucla.edu> wrote:
Is the BuiltinUsers.Key the api key or is this a different key I create?

For dataverse.ucla.edu users come in via Shibboleth, other authentications have been blocked. But I wanted to be able to create a local/builtin account from the api for exceptions such as visiting researcher.


Thank you,

Jamie

--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-commu...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-commu...@googlegroups.com.

To post to this group, send email to dataverse...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/fa652ea7-1dd6-46bf-9210-a9e91fc30e1e%40googlegroups.com.

Philip Durbin

unread,
May 10, 2019, 1:13:54 PM5/10/19
to dataverse...@googlegroups.com
Thanks for jumping in, Sherry.

Jamie and Sherry (and all), I'd feel remiss if I didn't mention that NTU has a very interesting "application for DR-NTU (data) account creation for non-NTU data depositors" sign up workflow at https://researchdata.ntu.edu.sg

It's a bit hard to explain but I hope the attached screenshots help.

In short, they made a custom form, linked from the "Sign Up" button. I don't know the details though.

Finally, I'm aware of an installation where they're toying with the idea of letting anyone log in with ORCID but only giving permission to create datasets to people they know and approve. This is similar to what Sherry is saying about TDL (ORCID instead of Google accounts, though).

I hope this helps,

Phil

p.s. Sherry, I think TDL does have a GUI login but they changed the button text from "Username/Email" to "Admin ID". Maybe the idea is that they promoted some institutional accounts to superuser but want a way to get in with the dataverseAdmin account if their institutional identity provider is down? I'm not sure.

To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/CADL9p-WV8CA15se_Cejw1D0rNVkUbRD9DBN9QLkK_B5Ruc3gUg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.
Screen Shot 2019-05-10 at 1.04.45 PM.png
Screen Shot 2019-05-10 at 1.04.51 PM.png

Jamie Jamison

unread,
May 10, 2019, 1:44:11 PM5/10/19
to dataverse...@googlegroups.com
Sherry,

Yes, I've set :AllowSignUp to false. In the event we need to set up an account for someone we want to be able to do it through the api.  

Similar to what you are doing - signup link is gone and only UCLA in the institution list.  Local/builtin account only for dataverseAdmin and anyone we might make an account for.

Jamie


You received this message because you are subscribed to a topic in the Google Groups "Dataverse Users Community" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dataverse-community/EXApk46Jm2I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dataverse-commu...@googlegroups.com.

To post to this group, send email to dataverse...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/CADL9p-WV8CA15se_Cejw1D0rNVkUbRD9DBN9QLkK_B5Ruc3gUg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


--
jam...@g.ucla.edu

UCLA Library Data Archive
310-825-0716

-----------------------------------------------------------------------------

"An asset is only an asset if you can access it ..."
AMIA (Association of Moving Image Archivists)/Digital Asset Symposium 2008

Jamie Jamison

unread,
May 10, 2019, 2:46:38 PM5/10/19
to Dataverse Users Community
Phil and Sherry,

I added a user via the api on our test system.  

I am going to add a pull request suggestion on the documentation, what the restrictions are for creating the BuiltinUsers.Key.  I found by process of error that dashes (-) aren't ok.  

Thank you again for the help,

Jamie

Su Nee Goh

unread,
May 13, 2019, 12:03:46 AM5/13/19
to Dataverse Users Community
Dear Phil,

Indeed, we're using a custom form on our university subscribed Verint survey platform to facilitate application for account creation for non-NTU people. The application has to be sponsored by a NTU person. A specific dataverse which the non-NTU person needs access, start date and end date for the access, will have to be specified in the application.

The application comes to the Library Research Data Management Team and we verify with the NTU sponsor named in the form. After verification, the Library helps to create an account for non-NTU person using a hidden URL. We create an initial password. We then send separate emails to the non-NTU person and the NTU sponsor. We share the steps to login using the newly created account with the non-NTU person, together with the advice to change the password.

We don't have a workflow to support ORCID login yet. Our target audience is NTU members, followed by their external collaborators upon request.

Hope this helps.

Su Nee, GOH
Nanyang Technological University Library
To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-community+unsub...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-community+unsub...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-community+unsub...@googlegroups.com.

Venkatachalam Kannadasan

unread,
May 13, 2019, 10:31:44 AM5/13/19
to Dataverse Users Community
Hi Jamie

I resolved this issue simply by using the configuration option :SignUpUrl and pointing it to the custom survey page for external members to request for an account. curl -X PUT -d '/dataverseuser.xhtml?editMode=CREATE' http://localhost:8080/api/admin/settings/:SignUpUrl

Then I removed the configuration for :AllowSignUp, if this is set to False we cannot access the actual SignUpUrl which is https://dataverse.harvard.edu/dataverseuser.xhtml;jsessionid=1965ccb93b33ba0f69e88b29fa4f?editMode=CREATE&redirectPage=%2Fdataverse_homepage.xhtml.

Now this URL is only known to our administrators and they use this form to create the accounts as requested in the survey form. As per your other message through the UI, many checks have been put in place for creating secured password hence we need not worry about it. When the account is created it triggers an email to the external member and we advise them to reset the password and then login.

Prior to this setup we use to create the accounts at the backend using API and email the users the login details.

Hope this helps.

Let me know if you have any questions.

Regards
Venki
DR-NTU(Data) at NTU, Singapore.

Reply all
Reply to author
Forward
0 new messages