Skip to first unread message
Hutchinson, Tim
Nov 19, 2018, 3:49:28 PM11/19/18
to ica-ato...@googlegroups.com
I’m trying to figure out what should be possible in terms of protecting master digital objects from public view.
Basically, with a representative image like:
… I can edit the URL to http://ouratomsite.ca/uploads/r/institution-name/a/b/b/abbe4a20c2a6d7e3c33be60f74e53b2fb3a21880aee8ad6b07010004f373494d/A-1.tif
(omitting the _141 and changing the extension) to gain access to the master. Because of this limitation (as I had understood it) we haven’t actually been upload high resolution masters.
But I can’t reproduce this on some other AtoM instances, so I’m wondering if we missed a server configuration or something else, following the addition of the PREMIS rights features. (From issue 2714, which mentions the URL issue, I’m gathering there’s a connection.)
We haven’t been using the PREMIS rights feature, and I haven’t spent a lot of time with it so I might be doing something wrong, but testing with a single description, if I set the rights as “conditional” (for which access to the master is not allowed), I can still get access to the master (for that description) by changing the URL. Denying access to the representative image works as expected.
Am I right in thinking that it should be possible to protect the master image from this kind of backdoor access? If so, how to do we implement that?
A possibly related issue: a lot of our images still have a location like:
http://ouratomsite.ca/uploads/r/institution-name/8/5/850534/photo10.jpg
in other words without the UUID. Any new uploads get the UUID. Is there a task we can run to standardize the existing uploads? I’m wondering if we missed something during a previous upgrade.
Thanks
Tim
Dan Gillean
Nov 20, 2018, 11:49:00 AM11/20/18
to ica-ato...@googlegroups.com
Hi Tim,
As far as I'm aware, if your permissions for anonymous users accessing the master digital object are set to Deny, then a public user trying to change the URL will simply lead to a page not found message. Try it:
If you're trying to prevent logged in users from accessing the master however, this won't work.
As to the missing UUIDs on some file paths - these are likely older uploads that predate the addition of the UUID. I mention another change similar to this in my older post about how digital objects are stored in AtoM, here:
Unfortunately, we don't currently have a task that would do what you're looking for, in terms of reorganizing older uploads to use the same hashed folder count and UUID structure across all digital objects. If this is something your institution might want to sponsor, feel free to get in touch with me off-list and I can follow up with our team.
You might also find the following post about editing the file path for digital object derivatives interesting:
The case you describe with the PREMIS rights when set to Conditional sounds like a bug to me. I will try to test to reproduce it soon, and file a bug report. We have an internal visioning retreat coming up over the next couple days, so please be patient!
Cheers,
--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/YQBPR0101MB137987D4E2B82C4380D483F3E0D80%40YQBPR0101MB1379.CANPRD01.PROD.OUTLOOK.COM.
For more options, visit https://groups.google.com/d/optout.
David Juhasz
Nov 20, 2018, 1:03:17 PM11/20/18
to ica-ato...@googlegroups.com
Hi Tim,
There is a key change to the Nginx configuration required to "turn on" digital object security for AtoM 2.2+. The necessary configuration is included in the installation documentation, but it can be easy to miss if you upgraded from AtoM <2.2:
The key lines for digital object security checks are:
location ~* /uploads/r/(.*)/conf/ {
}
location ~* ^/uploads/r/(.*)$ {
include /etc/nginx/fastcgi_params;
set $index /index.php;
fastcgi_param SCRIPT_FILENAME $document_root$index;
fastcgi_param SCRIPT_NAME $index;
fastcgi_pass atom;
}
location ~ ^/private/(.*)$ {
internal;
alias /usr/share/nginx/atom/$1;
}
The first block prevents access to "conf/" directories inside of the uploads path. The second block redirects requests for any files in the uploads/r/ path to the PHP AtoM controller (index.php) to do security checking. The third block passes the "internal" directive to Nginx to authorise loading the requested digital object.
I hope that helps!
David
--
David Juhasz Director, AtoM Technical Services Artefactual Systems Inc. www.artefactual.com
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZJ%3DzAo3arKobHf5uz76Ox5AixeRDEXE7XdC_pt9oJznfA%40mail.gmail.com.
Tim Hutchinson
Nov 20, 2018, 6:32:46 PM11/20/18
to AtoM Users
Thanks guys, I suspect it's the server block that explains things - we'll give that a try.
Dan, I might not have been clear in my description re conditional access. Other than the object being accessible via editing the URL, I think the PREMIS functionality was behaving as expected.
Tim
Darryl Friesen
Nov 22, 2018, 4:42:38 PM11/22/18
to AtoM Users
/usr/share/nginx/collections
/usr/share/nginx/items
etc.
For each one, out nginx config has a section like this (the location line has been adjusted to add the correct URL path portion for each instance):
location ~* ^/collections/uploads/r/(.*)$ {
include /etc/nginx/fastcgi_params;
set $index /collections/index.php;
fastcgi_param SCRIPT_FILENAME $document_root$index;
fastcgi_param SCRIPT_NAME $index;
fastcgi_pass atom-collections;
}
In the nginx log file I'm seeing requests for an image (GET /collections/uploads/r/blah-blah.jpg) which looks correct, but I'm getting a "No such file or directory" error because it's looking for this in /usr/share/nginx/atom/uploads/r/blah-blah.jpg).
Is there somewhere in the AtoM config I should be setting the physical file path? It seems to be using the default /usr/share/nginx/atom instead of where I actually have the code installed.
- Darryl
On Tuesday, November 20, 2018 at 12:03:17 PM UTC-6, David at Artefactual wrote:
David Juhasz
Nov 22, 2018, 7:32:14 PM11/22/18
to ica-ato...@googlegroups.com
Hi Darryl,
In the AtoM installation documentation for Nginx the AtoM root directory is set in the "server" block, but that only works with a single AtoM instance on the server.
...server {listen 80;root /usr/share/nginx/atom;...
For your case where you have multiple AtoM installations, you will need to define the "root" directive in the location blocks for each AtoM instance. I *think* this should work:
location ~* ^/collections/uploads/r/(.*)$ { root /path/to/atom;
include /etc/nginx/fastcgi_params;
set $index /collections/index.php;
fastcgi_param SCRIPT_FILENAME $document_root$index;
fastcgi_param SCRIPT_NAME $index;
fastcgi_pass atom-collections;
}
*But* you are also going to have to copy each of the three location blocks in my previous message for each of your AtoM installs, so you should have at least three location blocks per AtoM instance or do some fancy regex work to match and redirect to the correct AtoM install.
Best regards, David
--
David Juhasz Director, AtoM Technical Services Artefactual Systems Inc. www.artefactual.com
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/bf6064d5-3fae-475f-ac73-35ddadb2cb18%40googlegroups.com.
Darryl Friesen
Nov 27, 2018, 1:24:37 PM11/27/18
to AtoM Users
First, let me express my dislike for the nginx config. :) Having used Apache for 20+ years, I did not enjoy the 2 days I spent fighting with the various "location" blocks in nginx.
But I think I have this issue solved. Because we have multiple AtoM instances on the same server, each is served from a directory one down from the root; something like:
For each of "site1" and "site2" we have an "uploads" location defined like this:
location ~* ^/site1/uploads/r/(.*)$ {
root /usr/share/nginx/site1
include /etc/nginx/fastcgi_params;
set $index /index.php;
fastcgi_param SCRIPT_FILENAME $document_root$index;
fastcgi_param SCRIPT_NAME /site1$index;
fastcgi_pass atom-site1;
}
The problem is with this line in the setResponseHeaders() method of apps/qubit/modules/digitalobject/actions/viewAction.class.php
$this->response->setHttpHeader('X-Accel-Redirect', '/private'.$this->resource->getFullPath());This will redirect to the absolute URL
when attempting to fetch a file from the uploads folder instead of this:
http://hostname.server.com/site1/private/uploads/r/blah-blah-blah
That is, the path portion of the URL is lost on the redirect request. This will be an issue not just for institutions with multiple AtoM instances on the same server (like us), but any institution that might be trying to server static website content from the root of their server and may want AtoM installed in a subdirectory of that.
I fixed the issue by replacing the above line in viewAction/class.php with this:
$webRoot = str_replace('/index.php', '', $_SERVER['SCRIPT_NAME']);
$this->response->setHttpHeader('X-Accel-Redirect', $webRoot . '/private' . $this->resource->getFullPath());
This should retain the portion of the URL leading up to the AtoM install, and use that when making the redirect to the upload file.
- Darryl
David Juhasz
Nov 28, 2018, 4:26:53 PM11/28/18
to ica-ato...@googlegroups.com
Hi Darryl,
Awesome! Thank you for sharing your solution to the problem and good work on finding the URL hardcoding problem. I'd like to get your code fix into the public version of AtoM. Would you like to submit a pull request for the fix, or would you prefer if one of the Artefactual developers makes the change based off of the information you've provided here?
Best regards,
David
--
David Juhasz Director, AtoM Technical Services Artefactual Systems Inc. www.artefactual.com
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/1e2ec82b-db84-4b1d-bf1b-00100bcdf8b0%40googlegroups.com.
David Juhasz
Nov 28, 2018, 4:27:32 PM11/28/18
to ica-ato...@googlegroups.com
P.S. Sorry you had to resort to using Nginx. ;-)
Darryl Friesen
Nov 29, 2018, 9:35:06 AM11/29/18
to AtoM Users
- Darryl
Dan Gillean
Nov 29, 2018, 10:11:59 AM11/29/18
to ica-ato...@googlegroups.com
Hi Darryl,
If you do send a pull request, please submit it against qa/2.5.x. At this point, now that 2.4.1 has been released, our development is focused on the next major release (2.5) we don't expect to add more minor releases, barring something critical that necessitates it.
Cheers,
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/09037a26-5f6d-4c70-9db8-690546590ef8%40googlegroups.com.
Darryl Friesen
Nov 29, 2018, 3:59:37 PM11/29/18
to AtoM Users
Dan Gillean
Nov 30, 2018, 10:44:27 AM11/30/18
to ica-ato...@googlegroups.com
Thanks Darryl!
One of our developers will evaluate the PR soon, and will communicate with you there if anything else is needed.
We appreciate your contribution!
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/b848e5a1-49b8-450b-932f-2ca60d0efdf6%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages