Email file link to non-user

[#1]

Is it possible to email to someone a link to a file or folder in Alfresco Cloud so that they could download that single file or folder without needing to be a user.

My business involves sending files to unrelated, 3rd party on behalf of clients and this would improve the security of confidential information. I don't want nor can I expect these people to get their own login for my business Alfresco Cloud account.

It would be great to be able to email someone a link to a file rather than the actual file, being able to track when that link was accessed and then have the link stop working after a certain amount of time or after the file had been downloaded.

Thanks

[eswbitto]

I'm trying not to sound negative, but your post contradicts itself. You want to be able to send clients a link to access a file (download…etc), but how is that improving the security of confidentiality? I would think the premise behind (from what I understand) is that the documents that you are making available are confidential in nature. Am I right?

That being said if you want to send a link for people to download without any authentication required then you might as well put the documents on a webpage. That's basically what you are asking for. 

[#3]

I have been thinking more about the security as you mention and ask how the security of a user password, likely to be shared by email, compares to a long string of random characters for the URL of a shared file? Especially for non-frequent users who are likely to either record the password for easy access or would need an easy way to reset the password.

A hacker/thief would have less chance of guessing a unique, random and long URL. Also, people tend to record passwords and save emails with password details long after they would have deleted the email with the unique, random URL which can be more easily restricted in terms of use.

A hacker/thief, with access to a targets email, could gain access to the files either way with the main difference being that the intended recipient would be much more inconvenienced with a password than just a link.

[#4]

Thanks for your comments.

While I agree that my suggestion would reduce security compared to making the external 3rd party a user to the repository, I believe my suggestion is simpler and more secure than the alternative.

Without this ability, users will simply copy a file out of the repository and email to the external 3rd party. There will now be a copy of the confidential file sitting in our outbox, their inbox and anywhere else it has been saved, all without being able to prevent future access.

For all its faults, email is still the most universally accepted method of sending and receiving files and trying to change this for outside parties is simply not going to happen. I am just trying to make the current email method more secure by reducing the additional locations the files will otherwise be stored.

You are correct that we could temporarily put the files on an obscure webpage but still need a way to link that to the repository to avoid the file being stored in another place.

Thinking more about the security, if an email with a link to the file within the repository was intercepted, the hacker would need to access the link and file before the intended recipient in the case where the link allows for 1 download only.

[rjohnson]

Write a webscript that runs as admin and returns a content stream (special type of webscript) and expects 2 parameters; a noderef and a token. Generate a token when generating the email with the link, store that token in a datalist and write the link complete with noderef and token to the email body.

Your webscript can do all sorts of things before returning content. For example you could transform your documents into PDF and using one of the PDF libraries make that document "unsavable" locally, or "un printable" locally or watermark it. You could even apply a pre-agreed read password to it which was not in you link email.

With each call you can update a use counter on the token, so you can make it single use, multi use, forever use, you could apply an expiry date/time to it.

The email could end up in the wrong hands, if you worked that out you can kill the token, and I guess someone could have a bash at guessing a different noderef (I wish them luck on that) but you could easily cancel the token within your webscript if an attempt was made to access a node different from the one sent.

You need to make sure your tokens are not easily forgeable.

The security implications depends on the document content, you might worry a lot about the payroll data, rather less about a purchase order document for tools.

Bob Johnson

[#6]

That seems perfect. Now I need to learn how to write webscripts.

[rjohnson]

If you care to give me an email address, I will send you a (very) bare bones example of a webscript that returns content. There is a good tutorial on the web for handling datalists in javascript so you should be able to merge the 2 to achive what you need.

I would post the files here, but there seems to be a bug in the forums that means you cannot attach files.

Bob Johnson

[arm]

Hi Johnson

do u mind to send me the examples of the webscripts u said so, alfrescorm@gmail.com

plz

[#9]

Thank you for all your help and your offer to send an example of a webscript that returns content. I will share my solution on the forum once I get it working.