-
Notifications
You must be signed in to change notification settings - Fork 557
Fix URL signing api for URLs containing special characters #12435
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
base: develop
Are you sure you want to change the base?
Changes from 5 commits
f911647
2c94dc8
96be125
8812582
9cb852a
12216ba
942f3cf
4387ee9
8b1ab7b
4bbb576
4e8b6ff
77ba0c8
9a4d41f
96ec148
5706157
ddcf8ff
06f539e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,25 @@ | ||
| ### Signed URLs work again for URLs with special characters | ||
|
|
||
| Requesting a signed URL (e.g. via `/api/admin/requestSignedUrl`, used by external tools, the Globus | ||
| integration and third-party integrations) was broken for URLs whose query contained special | ||
| characters; most notably persistent IDs such as `doi:10.5072/FK2/ABC` (which contain `:` and | ||
| `/`), as well as spaces, percent-encoded values and non-ASCII characters. The signing logic had | ||
| started normalizing/re-encoding the URL before signing it, while the signature is a byte-exact MAC | ||
| over the URL string; the re-encoded bytes no longer matched what callers presented back, so | ||
| validation failed with "signature does not match"/authentication errors. | ||
|
|
||
| Signing is now byte-exact again: the base URL is preserved exactly as provided (reserved signing | ||
| parameters are still stripped, but without re-encoding the rest of the URL). Clients must continue to | ||
| present the signed URL exactly as Dataverse returned it. | ||
|
|
||
| ### A signing secret is now required to request signed URLs | ||
|
|
||
| The `/api/admin/requestSignedUrl` endpoint now requires a non-empty signing secret | ||
| (`dataverse.api.signing-secret`) to be configured. Previously an unset secret silently fell back to | ||
| using only the user's API token as the signing key, which is too weak. If the secret is not | ||
| configured, the endpoint now returns an error instead of issuing a weakly-signed URL. | ||
|
|
||
| **Upgrade note:** installations that use signed URLs through this endpoint (including the | ||
| `rdm-integration` connector) must set `dataverse.api.signing-secret`. See the | ||
| [Configuration Guide](https://guides.dataverse.org/en/latest/installation/config.html#dataverse-api-signing-secret). | ||
| Treat the value like a password. |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2453,7 +2453,13 @@ public Response getSignedUrl(@Context ContainerRequestContext crc, JsonObject ur | |
| if (superuser == null || !superuser.isSuperuser()) { | ||
| return error(Response.Status.FORBIDDEN, "Requesting signed URLs is restricted to superusers."); | ||
| } | ||
|
|
||
|
|
||
| // Require a signing secret: without it the key is only the user's API token, which is too weak. | ||
| if (JvmSettings.API_SIGNING_SECRET.lookupOptional().orElse("").isEmpty()) { | ||
| return error(Response.Status.BAD_REQUEST, | ||
| "Requesting signed URLs requires a signing secret to be configured. Please set the dataverse.api.signing-secret JVM option."); | ||
| } | ||
|
|
||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My concern with this being here is that it doesn't cover the URL signing when requesting a file download with a guestbook response. Those APIs still work without the secret. (See Access.java) These APIs all call UrlSignerUtil.signUrl, which should have this code to return an error if no signing-secret exists. {
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good catch. Two commits: first I added the same guard to the guestbook download ( I kept it out of Heads up: centralizing means all such signing now needs the secret: external tool/Globus callbacks and permission-history links too, not just the two endpoints. Every install using them must set That may be too much; happy to scope it back to just |
||
| String userId = urlInfo.getString("user"); | ||
| String key=null; | ||
| if (userId != null) { | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.