Blocked API Endpoints

[Sherry Lake]

I am trying to figure out how to protect our production installation and be able to use the API endpoints (for settings and other API calls).

For our Database settings:

We have the following blocked API endpoints: admin, builtin-users, test    (What/ who is "builtin-users"?)

We have our Blocked API Policy set to "localhost-only"

One case, I want to be able to change the Status Message Header without having my server admin do it for me (because they can log on to the localhost). 

My thought is I set :BlockedApiPolicy to "unblock-key"  and then use the :BlockedApiKey on my Status MessageHeader curl command. But then what do I need to set the BlockedApiEndpoints to? 

Do these API settings affect me "admin" (or dataverseAdmin) using other Native API endpoints? Or is a token (dataverseAdmin) is all that is needed for Native API endpoints.

I hope I have explained my confusion.

Thanks for helping me understand,

Sherry 

 

Sherry Lake | Scholarly Repository Librarian | University of Virginia Library | shL...@virginia.edu | 434.924.6730 | @shLakeUVA | Alderman Library, 160 N. McCormick Road, Charlottesville, VA 22903 | Alderman 563 | LinkedIn Profile | “Keeper of the Dataverse" 

[don sizemore]

Sherry,

I'm away from a computer at the moment, but if you're behind an Apache proxy you might be able to limit requests to /api/ to certain network ranges. This could likely be spoofed but may serve as an added layer of protection. I'm not sure what limiting /api/ might break, though.

Donald

painstakingly pecked on my iPhone.

--
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/3fe7a579-c6f1-410e-9684-86d77a6cda50%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[don sizemore]

oops, I meant to say /api/admin instead of /api

(or some combination of limits on each)

painstakingly pecked on my iPhone.

[Pete Meyer]

Hi Sherry,

Others probably know more about this than I do, but I might be able to shed a little light on some of your questions.

On Wednesday, August 9, 2017 at 3:23:35 PM UTC-4, Sherry Lake wrote:

I am trying to figure out how to protect our production installation and be able to use the API endpoints (for settings and other API calls).

For our Database settings:

We have the following blocked API endpoints: admin, builtin-users, test    (What/ who is "builtin-users"?)

"builtin-users" handles creating and editing dataverse users using the native authentication system (aka - not shibboleth or OAuth2).

 

We have our Blocked API Policy set to "localhost-only"

One case, I want to be able to change the Status Message Header without having my server admin do it for me (because they can log on to the localhost). 

My thought is I set :BlockedApiPolicy to "unblock-key"  and then use the :BlockedApiKey on my Status MessageHeader curl command. But then what do I need to set the BlockedApiEndpoints to? 

If :BlockedApiPolicy is "unblock-key", then I believe using curl with '-H "X-Dataverse-key: $key" (with $key being the value of :BlockedApiKey) will work without any changes to BlockedApiEndpoints - I haven't tested this though, and this is an area where other folks probably know more about it than I do. 

 

Do these API settings affect me "admin" (or dataverseAdmin) using other Native API endpoints? Or is a token (dataverseAdmin) is all that is needed for Native API endpoints.

My understanding is that the "admin" API covered by the block isn't related to the user being an admin or not.

 

I hope I have explained my confusion.

Thanks for helping me understand,

Sherry 

Hope I haven't added more confusion.

Best,

Pete

[Philip Durbin]

A minor correction is that if you use :BlockedApiKey you pass the key/password as the query parameter "unblock-key" as described at http://guides.dataverse.org/en/4.7.1/installation/config.html#blockedapikey

I'm not in love with that :BlockedApiKey setting and related "unblock-key" policy. I think "localhost-only" is more secure. It seems like Sherry's main reason for considering a switch from "localhost-only" is that she'd like to occasionally update settings such as the status message header. Probably what we should do is add to the superuser dashboard a view of what's in the settings table and the ability to add, edit, and delete what's there. You'd still have to read up on what the settings do but at least you would be able to make changes from a GUI rather than the command line with curl after ssh'ing to a server. If this sounds attractive to anyone reading this, please do not hesitate to create a GitHub issue.

Also, the "admin" API has little to do with the "Admin" role you see in the GUI. Originally (before we tagged 4.0) it was called "s" for "secure" (as in, be sure to secure this!) but we thought "admin" would better indicate that it's for administrative functions such as changing installation-wide settings.

I hope this helps. Obviously the docs could be improved. Here's the main entry point: http://guides.dataverse.org/en/4.7.1/installation/config.html#blocking-api-endpoints

Thanks,

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-community+unsub...@googlegroups.com.
To post to this group, send email to dataverse-community@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/0e661988-e3ae-441c-b253-e05601f5e4ae%40googlegroups.com.

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

--

Philip Durbin
Software Developer for http://dataverse.org
http://www.iq.harvard.edu/people/philip-durbin