Re: [MCN-L] Guessable web URLs
Hi Heidi, Thanks for the tip. I'm going to chew through all the responses I got and see what we can do. If anything exciting happens while we resolve this issue, I'll update the original post. Thanks again for weighing in, Emily. *--* *Emily Beliveau* Collections Management Advisor (Humanities) University of Alberta Museums Ring House 1, University of Alberta Edmonton, AB T6G 2E1 T: 780-492-0776 On Sat, May 2, 2020 at 7:47 AM Heidi Quicksilver wrote: > I’m not sure if this will be helpful or not but I know that there is a way > to create URL‘s that are not predictable. We did this on the last website > that I worked on because we had to create content that was super secret > before it was publicly released and we had people who were scraping our > site to try and figure out what the content was before we released it. We > were working with Gavin and Neil at Cogapp for the web development. Perhaps > they can help explain how they helped us create unpredictable URLs for web > pages. We were using Drupal 8. > > Heidi Q > Perez Art Museum Miami > Previously Rock & Roll Hall of Fame > hquicksil...@pamm.org > -- > Heidi Quicksilver > hquicksilver.com > 612-414-2001 > ___ > You are currently subscribed to mcn-l, the listserv of the Museum Computer > Network (http://www.mcn.edu) > > To post to this list, send messages to: mcn-l@mcn.edu > > To unsubscribe or change mcn-l delivery options visit: > http://mcn.edu/mailman/listinfo/mcn-l > > The MCN-L archives can be found at: > http://www.mail-archive.com/mcn-l@mcn.edu/ > ___ You are currently subscribed to mcn-l, the listserv of the Museum Computer Network (http://www.mcn.edu) To post to this list, send messages to: mcn-l@mcn.edu To unsubscribe or change mcn-l delivery options visit: http://mcn.edu/mailman/listinfo/mcn-l The MCN-L archives can be found at: http://www.mail-archive.com/mcn-l@mcn.edu/
Re: [MCN-L] Guessable web URLs
In principle it is best to have completely opaque identifiers for the web, and a separate system (which can be a simple as a couple of database tables) to keep track of the mapping. This is useful not as much for obscuring URLs (security through obscurity may work for short-term embargo as in your case, but becomes brittle for permanent URLs) as it is for sustainability. If your public URLs contain e.g. a TMS and/or NetEx ID, if you migrate out of either system you may not be able to retain those identifiers and will break all your public URLs. Stefano On 5/2/20 6:46 AM, Heidi Quicksilver wrote: I’m not sure if this will be helpful or not but I know that there is a way to create URL‘s that are not predictable. We did this on the last website that I worked on because we had to create content that was super secret before it was publicly released and we had people who were scraping our site to try and figure out what the content was before we released it. We were working with Gavin and Neil at Cogapp for the web development. Perhaps they can help explain how they helped us create unpredictable URLs for web pages. We were using Drupal 8. Heidi Q Perez Art Museum Miami Previously Rock & Roll Hall of Fame hquicksil...@pamm.org ___ You are currently subscribed to mcn-l, the listserv of the Museum Computer Network (http://www.mcn.edu) To post to this list, send messages to: mcn-l@mcn.edu To unsubscribe or change mcn-l delivery options visit: http://mcn.edu/mailman/listinfo/mcn-l The MCN-L archives can be found at: http://www.mail-archive.com/mcn-l@mcn.edu/
Re: [MCN-L] Guessable web URLs
I’m not sure if this will be helpful or not but I know that there is a way to create URL‘s that are not predictable. We did this on the last website that I worked on because we had to create content that was super secret before it was publicly released and we had people who were scraping our site to try and figure out what the content was before we released it. We were working with Gavin and Neil at Cogapp for the web development. Perhaps they can help explain how they helped us create unpredictable URLs for web pages. We were using Drupal 8. Heidi Q Perez Art Museum Miami Previously Rock & Roll Hall of Fame hquicksil...@pamm.org -- Heidi Quicksilver hquicksilver.com 612-414-2001 ___ You are currently subscribed to mcn-l, the listserv of the Museum Computer Network (http://www.mcn.edu) To post to this list, send messages to: mcn-l@mcn.edu To unsubscribe or change mcn-l delivery options visit: http://mcn.edu/mailman/listinfo/mcn-l The MCN-L archives can be found at: http://www.mail-archive.com/mcn-l@mcn.edu/
Re: [MCN-L] Guessable web URLs
Thanks all for the input. The main concern regarding access is meeting our legal obligation to rights holders, primarily for images of contemporary artwork. We will work with our copyright office to determine our risk strategy, but even with an open access model, we will need the ability to limit access to larger derivatives in certain cases. Separating the publishable vs. non-publishable images into separate directories makes perfect sense, it is figuring out some automation and management of the process that will be key (as Jeremy's comments address). I've lurked around the IIIF community for years, but the setup time/technical particulars have been a barrier in the past--perhaps it's time to reconsider. If we go that route, I'll surely be in touch with relevant folks for further advice. Thanks again, Emily. On Fri, May 1, 2020 at 12:23 PM Stefano Cossu wrote: > Emily, > I think others gave very valid suggestion that I mostly agree with, > especially about separating internal-use images with public ones. These > should reside in separate servers with clear firewall rules assigned. > Most importantly, you should isolate your internal management system > from the WWW. Assume your institution *will* (not *could*) be attacked > by malicious actors at any time. > > I support Jeremy's suggestion to look at IIIF. That takes some setup > time, as well as the need to produce specific derivatives. However, any > other image derivative is taken care of by the image server after that. > No need to manually generate thumbnail, web large/small/medium, etc. > > However, a IIIF manifest cannot enforce access to an image, it only > provides hints for good citizens about which derivatives they should > request. You can tackle restricted access in the same pipeline that > generates your IIIF-ready derivatives, by setting up a reduced > derivative size, or no public derivative at all, for > copyright-restricted images. This way you will have one folder / > repository with internal-only access behind firewall, and one open to > the WWW or behind the image server. > > This may sound like a lot to deal with, but in the long run it will > definitely save you a lot of management time, migration nightmares and > security loopholes. > > Stefano > > > On 5/1/20 10:41 AM, Jeremy Ottevanger wrote: > > Hi Emily, > > > > I'm going to leave for another thread the question of whether or not > > everything "should" be made available to the same degree - it's complex > > and not really what you're asking. But clearly that will be one element > > in people's assessment of whether the risk you're describing should be > > an issue or not. > > > > So, given that rights and licences are clearly important in your > > situation, would I think it a risk to leave a door ajar for people to > > take images you aren't meant to let them have? Well yes, it could be. Do > > I think people are likely to take them and abuse them? It's possible, of > > course, but perhaps it comes down the nature of the risks you want to > > avoid. If you could get into trouble with a rights holder that's one > > thing. But if you have an image licence sales team that is worried about > > lost revenue, I wouldn't worry so much. I don't think any commercial > > customer who is likely to have paid for a licence before is less likely > > to do so just because they figure out how to nick the image without > > paying. At the same time it can be a delicate political situation to get > > as far as you have and release any high-res images, in which case it can > > be canny politics to conspicuously avoid this risk. I've had to play > > this game in the past, even if I wanted to go much faster towards more > > open content, and in the end I believe it's really important to earn the > > trust of your organisation - it makes you a more plausible advocate for > > change anyway. > > > > So if there is a risk, what can you do to mitigate it? The obvious thing > > would be to put the images you want to publish into a separate directory > > to the ones you don't. That probably means having a second copy of them > > - that is surely the easiest solution. But if you can't do this for > > reasons of space (I hope not!) or of managing the process, I can think > > of a couple of other ways, although they could be equally tricky to > > automate or have other drawbacks. If this is a Linux server you could > > sim-link the published images to a location that you use for the web > > directory. Or you could do something clever with file permissions so > > that the web server (Apache or whatever) only has access to the > > published images (or with .htaccess). Both of these solutions could be > > automated, or semi-automated, for example by running a script over a > > list of files you want to sim-link. This might be built into the > > publication process. > > > > Or you could have a think about a IIIF solution (https://iiif.io/). > This > > has so many things going for it that go beyond what
Re: [MCN-L] Guessable web URLs
Emily, I think others gave very valid suggestion that I mostly agree with, especially about separating internal-use images with public ones. These should reside in separate servers with clear firewall rules assigned. Most importantly, you should isolate your internal management system from the WWW. Assume your institution *will* (not *could*) be attacked by malicious actors at any time. I support Jeremy's suggestion to look at IIIF. That takes some setup time, as well as the need to produce specific derivatives. However, any other image derivative is taken care of by the image server after that. No need to manually generate thumbnail, web large/small/medium, etc. However, a IIIF manifest cannot enforce access to an image, it only provides hints for good citizens about which derivatives they should request. You can tackle restricted access in the same pipeline that generates your IIIF-ready derivatives, by setting up a reduced derivative size, or no public derivative at all, for copyright-restricted images. This way you will have one folder / repository with internal-only access behind firewall, and one open to the WWW or behind the image server. This may sound like a lot to deal with, but in the long run it will definitely save you a lot of management time, migration nightmares and security loopholes. Stefano On 5/1/20 10:41 AM, Jeremy Ottevanger wrote: Hi Emily, I'm going to leave for another thread the question of whether or not everything "should" be made available to the same degree - it's complex and not really what you're asking. But clearly that will be one element in people's assessment of whether the risk you're describing should be an issue or not. So, given that rights and licences are clearly important in your situation, would I think it a risk to leave a door ajar for people to take images you aren't meant to let them have? Well yes, it could be. Do I think people are likely to take them and abuse them? It's possible, of course, but perhaps it comes down the nature of the risks you want to avoid. If you could get into trouble with a rights holder that's one thing. But if you have an image licence sales team that is worried about lost revenue, I wouldn't worry so much. I don't think any commercial customer who is likely to have paid for a licence before is less likely to do so just because they figure out how to nick the image without paying. At the same time it can be a delicate political situation to get as far as you have and release any high-res images, in which case it can be canny politics to conspicuously avoid this risk. I've had to play this game in the past, even if I wanted to go much faster towards more open content, and in the end I believe it's really important to earn the trust of your organisation - it makes you a more plausible advocate for change anyway. So if there is a risk, what can you do to mitigate it? The obvious thing would be to put the images you want to publish into a separate directory to the ones you don't. That probably means having a second copy of them - that is surely the easiest solution. But if you can't do this for reasons of space (I hope not!) or of managing the process, I can think of a couple of other ways, although they could be equally tricky to automate or have other drawbacks. If this is a Linux server you could sim-link the published images to a location that you use for the web directory. Or you could do something clever with file permissions so that the web server (Apache or whatever) only has access to the published images (or with .htaccess). Both of these solutions could be automated, or semi-automated, for example by running a script over a list of files you want to sim-link. This might be built into the publication process. Or you could have a think about a IIIF solution (https://iiif.io/). This has so many things going for it that go beyond what we're talking about here, but one salient point is that you aren't giving people direct access to a file - only the IIIF service on your server has access to the file, which it then does its magic on and sends out when requested. There is a manifest file containing information about the image, and if this isn't there then the IIIF service shouldn't return the image. I hope someone will correct me if I have that wrong! The downsides of IIIF would be that, firstly, you might not be publishing TIFFs like this, off the top of my head I'm not sure if that is supported by the spec or by any IIIF servers. And secondly, you'd need a way to publish manifests for each image you published. But once you did that you could have all the goodness that comes with IIIF and viewers like Mirador (https://projectmirador.org/) or Universal Viewer (https://universalviewer.io/) Good luck with your project, it's good to hear of more high resolution images being set free! All the best, Jeremy - Dr
Re: [MCN-L] Guessable web URLs
For what it's worth, systems like ContentDM present assets with guessable URLs too. So, I'm just pointing out that even those that have DAM systems this is an issue - whether they are aware of it or not. Joel Parham, MLIS JRP Consulting & Research, Inc. 310.923.4452 joel.par...@gmail.com On Fri, May 1, 2020 at 10:40 AM Emily Beliveau wrote: > Hi Sina, > > The way we're planning it, the media server will double as a storage > repository for all our media assets (masters and associated derivatives) so > everything will be in the same place in a predictable folder structure. We > only want to make some of the high-res images available for viewing or > download due to copyright. We could folder should-not-publish images > separately so they are not web accessible and can't be accessed by guessing > the URL, but in our current setup this would require manually moving files > around between web-accessible and non-web-accessible folders, and splitting > up the image sets for particular objects. Surely there is a better way, I'm > just hoping to find one that we can implement within the constraints of our > current IT environment, budget, and staff allocation. > > (I'm guessing this is a very junior-varsity question for the MCN group, but > this is where we are.) > > Emily. > > On Fri, May 1, 2020 at 10:31 AM Sina Bahram wrote: > > > Hi Emily, > > > > Just a high-level question, if I may, but if the resources are available > > for > > download, then is there a problem with having them be downloaded not > > through > > your search page? This seems like a feature, not a bug, IMHO. > > > > Take care, > > Sina > > > > President, Prime Access Consulting, Inc. > > Phone: 919-345-3832 > > https://www.PAC.bz > > Twitter: @SinaBahram > > Personal Website: https://www.sinabahram.com > > > > -Original Message- > > From: mcn-l On Behalf Of Emily Beliveau > > Sent: Friday, May 1, 2020 11:22 AM > > To: mcn-l@mcn.edu > > Subject: [MCN-L] Guessable web URLs > > > > Hi all (and attn: DAM and IP SIG members particularly) > > > > We are setting up a new media server that will allow us to provide > high-res > > image downloads via our collections search site for the first time > > (previously only small derivatives were web-accessible and our .tifs were > > stored elsewhere). We can control the publish-to-web status of each level > > of image derivative with our collections management system, but since all > > the high-resolution files will be on the same server, the URLs for all > > images (regardless of rights/publish status) will be guessable. > > > > How is this commonly handled? For context, we do not have a DAMS and > manage > > all our files in folders manually. We currently have ~80K image assets. > I'd > > like to understand our options and whether the community views this as an > > issue or not. > > > > Thanks, > > Emily. > > > > *--* > > > > *Emily Beliveau* > > > > Collections Management Advisor (Humanities) > > > > University of Alberta Museums > > Ring House 1, University of Alberta > > Edmonton, AB T6G 2E1 > > T: 780-492-0776 > > ___ > > You are currently subscribed to mcn-l, the listserv of the Museum > Computer > > Network (http://www.mcn.edu) > > > > To post to this list, send messages to: mcn-l@mcn.edu > > > > To unsubscribe or change mcn-l delivery options visit: > > http://mcn.edu/mailman/listinfo/mcn-l > > > > The MCN-L archives can be found at: > > http://www.mail-archive.com/mcn-l@mcn.edu/ > > > > ___ > > You are currently subscribed to mcn-l, the listserv of the Museum > Computer > > Network (http://www.mcn.edu) > > > > To post to this list, send messages to: mcn-l@mcn.edu > > > > To unsubscribe or change mcn-l delivery options visit: > > http://mcn.edu/mailman/listinfo/mcn-l > > > > The MCN-L archives can be found at: > > http://www.mail-archive.com/mcn-l@mcn.edu/ > > > ___ > You are currently subscribed to mcn-l, the listserv of the Museum Computer > Network (http://www.mcn.edu) > > To post to this list, send messages to: mcn-l@mcn.edu > > To unsubscribe or change mcn-l delivery options visit: > http://mcn.edu/mailman/listinfo/mcn-l > > The MCN-L archives can be found at: > http://www.mail-archive.com/mcn-l@mcn.edu/ > ___ You are currently subscribed to mcn-l, the listserv of the Museum Computer Network (http://www.mcn.edu) To post to this list, send messages to: mcn-l@mcn.edu To unsubscribe or change mcn-l delivery options visit: http://mcn.edu/mailman/listinfo/mcn-l The MCN-L archives can be found at: http://www.mail-archive.com/mcn-l@mcn.edu/
Re: [MCN-L] Guessable web URLs
If you're saying that you're setting up a system where images you don't want to be public are on a public server, you can be sure they will get out sooner or later. Probably more or less immediately, especially if you're not black belts in robots.txt fu. What is this system? -- Matt Morgan m...@concretecomputing.com On Fri, May 1, 2020, at 5:37 PM, Emily Beliveau wrote: > Hi Sina, > > The way we're planning it, the media server will double as a storage > repository for all our media assets (masters and associated derivatives) so > everything will be in the same place in a predictable folder structure. We > only want to make some of the high-res images available for viewing or > download due to copyright. We could folder should-not-publish images > separately so they are not web accessible and can't be accessed by guessing > the URL, but in our current setup this would require manually moving files > around between web-accessible and non-web-accessible folders, and splitting > up the image sets for particular objects. Surely there is a better way, I'm > just hoping to find one that we can implement within the constraints of our > current IT environment, budget, and staff allocation. > > (I'm guessing this is a very junior-varsity question for the MCN group, but > this is where we are.) > > Emily. > > On Fri, May 1, 2020 at 10:31 AM Sina Bahram wrote: > > > Hi Emily, > > > > Just a high-level question, if I may, but if the resources are available > > for > > download, then is there a problem with having them be downloaded not > > through > > your search page? This seems like a feature, not a bug, IMHO. > > > > Take care, > > Sina > > > > President, Prime Access Consulting, Inc. > > Phone: 919-345-3832 > > https://www.PAC.bz > > Twitter: @SinaBahram > > Personal Website: https://www.sinabahram.com > > > > -Original Message- > > From: mcn-l On Behalf Of Emily Beliveau > > Sent: Friday, May 1, 2020 11:22 AM > > To: mcn-l@mcn.edu > > Subject: [MCN-L] Guessable web URLs > > > > Hi all (and attn: DAM and IP SIG members particularly) > > > > We are setting up a new media server that will allow us to provide high-res > > image downloads via our collections search site for the first time > > (previously only small derivatives were web-accessible and our .tifs were > > stored elsewhere). We can control the publish-to-web status of each level > > of image derivative with our collections management system, but since all > > the high-resolution files will be on the same server, the URLs for all > > images (regardless of rights/publish status) will be guessable. > > > > How is this commonly handled? For context, we do not have a DAMS and manage > > all our files in folders manually. We currently have ~80K image assets. I'd > > like to understand our options and whether the community views this as an > > issue or not. > > > > Thanks, > > Emily. > > > > *--* > > > > *Emily Beliveau* > > > > Collections Management Advisor (Humanities) > > > > University of Alberta Museums > > Ring House 1, University of Alberta > > Edmonton, AB T6G 2E1 > > T: 780-492-0776 > > ___ > > You are currently subscribed to mcn-l, the listserv of the Museum Computer > > Network (http://www.mcn.edu) > > > > To post to this list, send messages to: mcn-l@mcn.edu > > > > To unsubscribe or change mcn-l delivery options visit: > > http://mcn.edu/mailman/listinfo/mcn-l > > > > The MCN-L archives can be found at: > > http://www.mail-archive.com/mcn-l@mcn.edu/ > > > > ___ > > You are currently subscribed to mcn-l, the listserv of the Museum Computer > > Network (http://www.mcn.edu) > > > > To post to this list, send messages to: mcn-l@mcn.edu > > > > To unsubscribe or change mcn-l delivery options visit: > > http://mcn.edu/mailman/listinfo/mcn-l > > > > The MCN-L archives can be found at: > > http://www.mail-archive.com/mcn-l@mcn.edu/ > > > ___ > You are currently subscribed to mcn-l, the listserv of the Museum > Computer Network (http://www.mcn.edu) > > To post to this list, send messages to: mcn-l@mcn.edu > > To unsubscribe or change mcn-l delivery options visit: > http://mcn.edu/mailman/listinfo/mcn-l > > The MCN-L archives can be found at: > http://www.mail-archive.com/mcn-l@mcn.edu/ > ___ You are currently subscribed to mcn-l, the listserv of the Museum Computer Network (http://www.mcn.edu) To post to this list, send messages to: mcn-l@mcn.edu To unsubscribe or change mcn-l delivery options visit: http://mcn.edu/mailman/listinfo/mcn-l The MCN-L archives can be found at: http://www.mail-archive.com/mcn-l@mcn.edu/
Re: [MCN-L] Guessable web URLs
Hi Emily, I'm going to leave for another thread the question of whether or not everything "should" be made available to the same degree - it's complex and not really what you're asking. But clearly that will be one element in people's assessment of whether the risk you're describing should be an issue or not. So, given that rights and licences are clearly important in your situation, would I think it a risk to leave a door ajar for people to take images you aren't meant to let them have? Well yes, it could be. Do I think people are likely to take them and abuse them? It's possible, of course, but perhaps it comes down the nature of the risks you want to avoid. If you could get into trouble with a rights holder that's one thing. But if you have an image licence sales team that is worried about lost revenue, I wouldn't worry so much. I don't think any commercial customer who is likely to have paid for a licence before is less likely to do so just because they figure out how to nick the image without paying. At the same time it can be a delicate political situation to get as far as you have and release any high-res images, in which case it can be canny politics to conspicuously avoid this risk. I've had to play this game in the past, even if I wanted to go much faster towards more open content, and in the end I believe it's really important to earn the trust of your organisation - it makes you a more plausible advocate for change anyway. So if there is a risk, what can you do to mitigate it? The obvious thing would be to put the images you want to publish into a separate directory to the ones you don't. That probably means having a second copy of them - that is surely the easiest solution. But if you can't do this for reasons of space (I hope not!) or of managing the process, I can think of a couple of other ways, although they could be equally tricky to automate or have other drawbacks. If this is a Linux server you could sim-link the published images to a location that you use for the web directory. Or you could do something clever with file permissions so that the web server (Apache or whatever) only has access to the published images (or with .htaccess). Both of these solutions could be automated, or semi-automated, for example by running a script over a list of files you want to sim-link. This might be built into the publication process. Or you could have a think about a IIIF solution (https://iiif.io/). This has so many things going for it that go beyond what we're talking about here, but one salient point is that you aren't giving people direct access to a file - only the IIIF service on your server has access to the file, which it then does its magic on and sends out when requested. There is a manifest file containing information about the image, and if this isn't there then the IIIF service shouldn't return the image. I hope someone will correct me if I have that wrong! The downsides of IIIF would be that, firstly, you might not be publishing TIFFs like this, off the top of my head I'm not sure if that is supported by the spec or by any IIIF servers. And secondly, you'd need a way to publish manifests for each image you published. But once you did that you could have all the goodness that comes with IIIF and viewers like Mirador (https://projectmirador.org/) or Universal Viewer (https://universalviewer.io/) Good luck with your project, it's good to hear of more high resolution images being set free! All the best, Jeremy - Dr Jeremy Ottevanger Director, Sesamoid Consulting Limited t: +44(0)1787 475 487 m: +44(0)7865 887 887 e: jer...@ottevanger.co.uk w: https://sesamoidconsulting.co.uk/ twitter: @jottevanger LinkedIn: www.linkedin.com/in/jeremy-ottevanger On 01/05/2020 16:21, Emily Beliveau wrote: Hi all (and attn: DAM and IP SIG members particularly) We are setting up a new media server that will allow us to provide high-res image downloads via our collections search site for the first time (previously only small derivatives were web-accessible and our .tifs were stored elsewhere). We can control the publish-to-web status of each level of image derivative with our collections management system, but since all the high-resolution files will be on the same server, the URLs for all images (regardless of rights/publish status) will be guessable. How is this commonly handled? For context, we do not have a DAMS and manage all our files in folders manually. We currently have ~80K image assets. I'd like to understand our options and whether the community views this as an issue or not. Thanks, Emily. *--* *Emily Beliveau* Collections Management Advisor (Humanities) University of Alberta Museums Ring House 1, University of Alberta Edmonton, AB T6G 2E1 T: 780-492-0776 ___ You are currently subscribed to mcn-l, the listserv of the Museum Computer Network
Re: [MCN-L] Guessable web URLs
Hi Sina, The way we're planning it, the media server will double as a storage repository for all our media assets (masters and associated derivatives) so everything will be in the same place in a predictable folder structure. We only want to make some of the high-res images available for viewing or download due to copyright. We could folder should-not-publish images separately so they are not web accessible and can't be accessed by guessing the URL, but in our current setup this would require manually moving files around between web-accessible and non-web-accessible folders, and splitting up the image sets for particular objects. Surely there is a better way, I'm just hoping to find one that we can implement within the constraints of our current IT environment, budget, and staff allocation. (I'm guessing this is a very junior-varsity question for the MCN group, but this is where we are.) Emily. On Fri, May 1, 2020 at 10:31 AM Sina Bahram wrote: > Hi Emily, > > Just a high-level question, if I may, but if the resources are available > for > download, then is there a problem with having them be downloaded not > through > your search page? This seems like a feature, not a bug, IMHO. > > Take care, > Sina > > President, Prime Access Consulting, Inc. > Phone: 919-345-3832 > https://www.PAC.bz > Twitter: @SinaBahram > Personal Website: https://www.sinabahram.com > > -Original Message- > From: mcn-l On Behalf Of Emily Beliveau > Sent: Friday, May 1, 2020 11:22 AM > To: mcn-l@mcn.edu > Subject: [MCN-L] Guessable web URLs > > Hi all (and attn: DAM and IP SIG members particularly) > > We are setting up a new media server that will allow us to provide high-res > image downloads via our collections search site for the first time > (previously only small derivatives were web-accessible and our .tifs were > stored elsewhere). We can control the publish-to-web status of each level > of image derivative with our collections management system, but since all > the high-resolution files will be on the same server, the URLs for all > images (regardless of rights/publish status) will be guessable. > > How is this commonly handled? For context, we do not have a DAMS and manage > all our files in folders manually. We currently have ~80K image assets. I'd > like to understand our options and whether the community views this as an > issue or not. > > Thanks, > Emily. > > *--* > > *Emily Beliveau* > > Collections Management Advisor (Humanities) > > University of Alberta Museums > Ring House 1, University of Alberta > Edmonton, AB T6G 2E1 > T: 780-492-0776 > ___ > You are currently subscribed to mcn-l, the listserv of the Museum Computer > Network (http://www.mcn.edu) > > To post to this list, send messages to: mcn-l@mcn.edu > > To unsubscribe or change mcn-l delivery options visit: > http://mcn.edu/mailman/listinfo/mcn-l > > The MCN-L archives can be found at: > http://www.mail-archive.com/mcn-l@mcn.edu/ > > ___ > You are currently subscribed to mcn-l, the listserv of the Museum Computer > Network (http://www.mcn.edu) > > To post to this list, send messages to: mcn-l@mcn.edu > > To unsubscribe or change mcn-l delivery options visit: > http://mcn.edu/mailman/listinfo/mcn-l > > The MCN-L archives can be found at: > http://www.mail-archive.com/mcn-l@mcn.edu/ > ___ You are currently subscribed to mcn-l, the listserv of the Museum Computer Network (http://www.mcn.edu) To post to this list, send messages to: mcn-l@mcn.edu To unsubscribe or change mcn-l delivery options visit: http://mcn.edu/mailman/listinfo/mcn-l The MCN-L archives can be found at: http://www.mail-archive.com/mcn-l@mcn.edu/
Re: [MCN-L] Guessable web URLs
Hi Emily, Just a high-level question, if I may, but if the resources are available for download, then is there a problem with having them be downloaded not through your search page? This seems like a feature, not a bug, IMHO. Take care, Sina President, Prime Access Consulting, Inc. Phone: 919-345-3832 https://www.PAC.bz Twitter: @SinaBahram Personal Website: https://www.sinabahram.com -Original Message- From: mcn-l On Behalf Of Emily Beliveau Sent: Friday, May 1, 2020 11:22 AM To: mcn-l@mcn.edu Subject: [MCN-L] Guessable web URLs Hi all (and attn: DAM and IP SIG members particularly) We are setting up a new media server that will allow us to provide high-res image downloads via our collections search site for the first time (previously only small derivatives were web-accessible and our .tifs were stored elsewhere). We can control the publish-to-web status of each level of image derivative with our collections management system, but since all the high-resolution files will be on the same server, the URLs for all images (regardless of rights/publish status) will be guessable. How is this commonly handled? For context, we do not have a DAMS and manage all our files in folders manually. We currently have ~80K image assets. I'd like to understand our options and whether the community views this as an issue or not. Thanks, Emily. *--* *Emily Beliveau* Collections Management Advisor (Humanities) University of Alberta Museums Ring House 1, University of Alberta Edmonton, AB T6G 2E1 T: 780-492-0776 ___ You are currently subscribed to mcn-l, the listserv of the Museum Computer Network (http://www.mcn.edu) To post to this list, send messages to: mcn-l@mcn.edu To unsubscribe or change mcn-l delivery options visit: http://mcn.edu/mailman/listinfo/mcn-l The MCN-L archives can be found at: http://www.mail-archive.com/mcn-l@mcn.edu/ ___ You are currently subscribed to mcn-l, the listserv of the Museum Computer Network (http://www.mcn.edu) To post to this list, send messages to: mcn-l@mcn.edu To unsubscribe or change mcn-l delivery options visit: http://mcn.edu/mailman/listinfo/mcn-l The MCN-L archives can be found at: http://www.mail-archive.com/mcn-l@mcn.edu/
[MCN-L] Guessable web URLs
Hi all (and attn: DAM and IP SIG members particularly) We are setting up a new media server that will allow us to provide high-res image downloads via our collections search site for the first time (previously only small derivatives were web-accessible and our .tifs were stored elsewhere). We can control the publish-to-web status of each level of image derivative with our collections management system, but since all the high-resolution files will be on the same server, the URLs for all images (regardless of rights/publish status) will be guessable. How is this commonly handled? For context, we do not have a DAMS and manage all our files in folders manually. We currently have ~80K image assets. I'd like to understand our options and whether the community views this as an issue or not. Thanks, Emily. *--* *Emily Beliveau* Collections Management Advisor (Humanities) University of Alberta Museums Ring House 1, University of Alberta Edmonton, AB T6G 2E1 T: 780-492-0776 ___ You are currently subscribed to mcn-l, the listserv of the Museum Computer Network (http://www.mcn.edu) To post to this list, send messages to: mcn-l@mcn.edu To unsubscribe or change mcn-l delivery options visit: http://mcn.edu/mailman/listinfo/mcn-l The MCN-L archives can be found at: http://www.mail-archive.com/mcn-l@mcn.edu/
