Change Allow Unrestricted Access' to 'No'

(Nassep) #1

hello


What would happen if we changed 'Allow Unrestricted Access' to 'No' on PDF and documents - what is the impact if we did this to all of our PDFs etc…



Is there a global setting for this?



Rgds



Angela

(Mohamed Haidar) #2

[quote]
hello



What would happen if we changed 'Allow Unrestricted Access' to 'No' on PDF and documents - what is the impact if we did this to all of our PDFs etc…



Is there a global setting for this?



Rgds



Angela

[/quote]



This means that you want to control the permissions to access this document and so it will be served by a normal matrix URL. If the File is Live with Public Permissions and Allow Unrestricted Access is On, then the file will be served by apache directly off the file system to anyone. The advantage of this is that it is much much faster than serving through Matrix.

There is no global setting for this that I know of.

(Edison Wang) #3

Can i ask why do you need to do remaps for PDF files?

(Greg Sherwood) #4

[quote]
Can i ask why do you need to do remaps for PDF files?

[/quote]



Maybe the filename changed and they don't want external bookmarks to break.



The answer to the original question is that the URL would change to be a friendly Matrix URL and that the file will be served slower.



If this is a one-off, you could consider adding some sort of redirect into Apache directly and retaining your __data URLs and the performance they provide. You'll need a system admin to do that if you don't know how to play around in the Apache config files. But if you do it frequently, you may want to consider a few other options, such as:


  1. Changed naming conventions. For example, instead of annual-report-2011.pdf and annual-report-2012.pdf, use annual-report-latest.pdf for the most current version and then archive it off under it's full name including the year. Obviously this is just an example and I'm not sure if it is applicable to you.


  2. Try using redirect page assets to do a similar thing. We used this for the Matrix downloads for quite a while. We configured a redirect page at matrix.squiz.net/download/mysource-matrix.tgz (something like that) which obviously has a friendly URL. We set the redirect page to point to the latest version of the Matrix download (would normally have an __data URL) and we changed this each time we created a new version. So when the user accessed (and bookmarked) matrix.squiz.net/download/mysource-matrix.tgz, it would always redirect to the latest version inside __data.



    Hope some of that helps.
(Charlotte Westney) #5

We're looking at doing this for all our pdfs (10,000s of them) for a couple of reasons:


Google is somehow indexing pdfs with the /__data/… urls under just one of our domains, so pdfs from one site are appearing in Google with the domain of another site, which really confuses people and has lead to quite a few emails to explain things to the public.



The other more serious issue, is that with the /__data urls, the pdfs don't inherit any permissions that are set on pages. But if we move our pdfs into the site struuctre and set unrestricted access to NO, then the pdfs should inherit the permissions. This makes it a lot easier for our editors to be able to control locked down areas of their sites, and to know that pdfs can't be seen as well as pages.



I'm aware that it will have an impact on our sites performance, and download times for pdfs, but I can't think of another way of ensuring that pdfs are only ever seen on the right domain and inherit permissions easily. Unless I'm missing a trick?



Thanks,

Charlie.

(Greg Sherwood) #6

[quote]
I'm aware that it will have an impact on our sites performance, and download times for pdfs, but I can't think of another way of ensuring that pdfs are only ever seen on the right domain and inherit permissions easily. Unless I'm missing a trick?

[/quote]



No, you're not missing anything. If you want control over everything (URLs and permissions in particular) you need to let Matrix manage the file. That does mean it takes longer to serve the file. It is most certainly a trade-off and is why we only use __data for file assets that are Live and have public read permission. If they are restricted in any way, the __data URL is removed and the file can no longer be accessed via it.