Secure Downloads

I changed this behaviour by adding the following lines in class.tx_nawsecuredl_output.php after line 63:

if ($this->u == 0){
header('HTTP/1.1 403 Forbidden');
exit ('Access denied!');
}

What I don’t understand is why the extension normally lets non logged in users (like Googlebot) download files regularly? What is the intention of doing this?

If you want your files to be protected, make sure they are only linked from protected pages/ content elements, because then only links with a the currently logged in user are created.

-> This is exactly what I did (the content elements / pages were protected to some user groups), but then one time a Google Bot came and found the links and even links that were never published. The search engine just knew the link and the link of course had u=0. If u=0 doesn’t output the requested file, it would have never indexed.
Another case: One logged in visitor publishes one of the naw_secure downloads. The person could post them somewhere in the internet or email the link or…. So this can not be named secure.
In short, if u=0 outputs the requested file, it is open for public, not secure.

In the case you explained with the images in uploads/pics/, typo3temp/pics/… this should be fine. But this case is not very often and also not secure, the person just has to surf to the page and save the image then (the only protection is against direct download). And a Googlebot would also crawl the images.

In my case the end of the story was that I had lots of naw_securedl links to PDFs online with u=0 in the search engine index.

Helmut Hummel wrote:

-> This is exactly what I did (the content elements / pages were protected to some user groups), but then one time a Google Bot came and found the links and even links that were never published. The search engine just knew the link and the link of course had u=0. If u=0 doesn’t output the requested file, it would have never indexed.

Sorry, but this just can't be true! All links, even with u=0 have a hash that is includes all parameters and a secret value (Encryption Key). Nobody can generate links without knowing this key, except the TYPO3 installation itself (or extensions of course).

I checked that again and you’re right, the hash value must be right for u=0.

Another case: One logged in visitor publishes one of the naw_secure downloads. The person could post them somewhere in the internet or email the link or…. So this can not be named secure. In short, if u=0 outputs the requested file, it is open for public, not secure.

If a user is logged in, the links does not have u=0 but the uid of the logged in user is in this parameter. Sharing such a link would not work because then it is checked if the user is logged in!

Right.

In the case you explained with the images in uploads/pics/, typo3temp/pics/… this should be fine. But this case is not very often and also not secure, the person just has to surf to the page and save the image then (the only protection is against direct download). And a Googlebot would also crawl the images.

I cannot follow. How would you want to "secure" a file on one hand but deliver it to one user on the other hand. Of course if the file is shown to a logged in user, he or she could download it and send it to someone else. No way to avoid that.

I just want to give no access to non logged in user (u=0), even if the content element is access protected. Let’s just suppose an editor forgets this or … (I don’t know what other ways/tricks exist so that Google could find such links). Imagine a case where PDFs for download have to be protected and not images from content elements.

In my case the end of the story was that I had lots of naw_securedl links to PDFs online with u=0 in the search engine index.

As mentioned above, such links cannot be forged and are only generated by the extension if the element is rendered without a user being logged in. How should google be able to access protected TYPO3 pages or elements?

I don’t know, maybe by forgeting to protect the content element by the editor? But Google found also other links, that were never published, I have no explanation. That’s also why I want to make that security thing more secure.

OK. So you have a specific protected folder where you want to deny download requests if no user is logged in? That could somehow make sense as additional safety net. But I'm not sure if it is worth adding yet another configuration option for this.

Exactly! It would be for additional security. I think one Typoscript option (as I mentioned in the other issue) would be good and people who don’t need it, don’t have to care.

Now we're talking. This may well be. The also the "secret" content of the page has been indexed by google and was accessible. Did I mention that all links generated are valid only for a certain time period? And if you want to immediately invalidate all links (in an emergency case), you could just change the encryption key.

The time period is a good thing and the encyption key changing would also help, but doesn’t help so much because of the Google Cache. One time it is indexed, the link could not be accessible, but the content can be accessed via the Google Cache.

The time period is a good thing and the encyption key changing would also help, but doesn’t help so much because of the Google Cache. One time it is indexed, the link could not be accessible, but the content can be accessed via the Google Cache.

I talked about file download security in this special context not about the problem of shouting out secrets in a crowded place and these secrets being "cached" in the peoples brains...

So what’s your conclusion? How about just adding a typoscript option like
plugin.tx_nawsecuredl.disableNonLoggedInAccess = 1
Which should if set to 1 totally forbid the download if u=0. In this case if the option is not set (standard setting), the extension behaviour is like it is actually and would work without problems when it is used e.g. for images (your example above). And if the extension is used to protect files which should really only get accessed by logged in users, just the typoscript must be set and everything is ready to go. And in PHP the if condition like in my first post could be used with jus one if clause before where the typoscript option will be checked. Another advantage: It could be set different on different locations of the website via ext templates. Should be like this:

if ($this->extConf['disableNonLoggedInAccess'] = 1) {
if ($this->u == 0){
header('HTTP/1.1 403 Forbidden');
exit ('Access denied!');
}
}

I just wanna make the extension better for the purposes it could be used. The time period is good for later, but if only the people who are really allowed to access the download (logged in users, no crawlers…), search engines could never get to index it and there would be no reason to play with the time period. Imagine you have a website to work on and the owner tells you that the downloads in directory xy should be secured so nobody who is not logged in, should not be able to download it (included search engines). So you would do as much as you can do, to also avoid human mistakes, so the download should really only be downloadable for logged in people (to be safe).

So what’s your conclusion? How about just adding a typoscript option like plugin.tx_nawsecuredl.disableNonLoggedInAccess = 1 Another advantage: It could be set different on different locations of the website via ext templates. Should be like this:

TypoScript is not possible and different configurations for different locations does not make any sense because the context of a page is not there when delivering the file.

I just wanna make the extension better for the purposes it could be used.

Two options you have:

1. You provide a patch that works and makes sense
2. You pay us to work on a solution

If you're interested in sponsoring such a feature please get in touch with us by mail. Thanks.

Okay, I’ll try myself first and have a closer look at the extension, otherwise sponsoring of course. So a checkbox in the extension settings would make sense, right?

I just found a solution that works perfect and there is no line php necessary to change. Simply by adding this into .htaccess:

1. For the secured downloads (extra Security)
   RewriteCond %{REQUEST_URI} ^/index\.php
   RewriteCond %{QUERY_STRING} ^eID=tx_nawsecuredl&u=0
   RewriteRule ^index.php* - [F]

So there wouldn’t be any change necessary, but I think it would be nice for others, if you add this .htaccess Code into the manual. Would that be possible?
It should also be possible to check the fe user by cookie.