smd_access_keys: secure, limited access to content

jayrope · 2011-07-20 12:46:07

Hi Stef,
if i use your example i still expose the generated key inside the variable “key” <txp:jnm_audio url='<txp:variable name="key" />' /> – and the original file path remains visible within the generated path. Also

A generated link holding the key on
http://domain.com/musicplayer
still looks like
http://domain.com/musicalities/test.mp3/test/5bdbc2abd391174b397dea9b1e207bd8c2cdb092/4e26b80d
and i get a 404 on direct access of this link whilst the mp3 player says “file not found”. Rrrr.

Note: http://domain.com/musicalities/test.mp3 does exist.
The directory “musicalities” is not protected otherwise.
(I will set up a .htaccess protection to test as soon as i figure out a working obfusctaed link – however using ONLY this to protect the files would still expose a)

What am i doing wrong there?

Of course idealistically the link should look similar to
http://domain.com/musicplayer/test/5bdbc2abd391174b397dea9b1e207bd8c2cdb092/4e26b80d

Looking at your current URL/key scheme i think there is not much missing, besides what i needed was, that the full download path disappears from the key’d URL.

Note: I am deriving this whole idea from http://radioartnet.net/11/2011/07/05/samuel-beckett-words-and-music/
When you look into the source there you see that the mp3 link looks like this:
aHR0cDovL3VidW1leGljby5jZW50cm8ub3JnLm14L3NvdW5kL2JlY2tldHRfc2FtdWVsL3RoZWF0cmVfcGllY2VzL0JlY2tldHQtU2FtdWVsX1RoZWF0cmUtRm9yLVlvdXItTW90aGVyX1dvcmRzK011c2ljLm1wMw

I guess i have no clue how they encode this.

…

The timeout for file downloads is governed by a plugin preference. Default is 3600 seconds […] I’d consider lowering it still further to, say, 15 minutes.

If mp3 files are very long, they will probably still play from the browser buffer provided they downloaded to the player within the time limit. That’s good.
I will have to rethink the pros and cons of individual visitor key creation vs. timed-one-key-for-all-page-visitors creation. i am not expecting loads of visitors (yet), so individual keys will probably not endlessly pile up. But… i will eventually need to sync the key generation with asy_jpcache working at the same time. Sounds like fun, or maybe a cache clearance call from smd_access_keys to asy_jpcache upon creation of a new page key. Only if there is just one key on that page, oh my… ;)

Both outlined automated key deletion options sound good, and the outlined trigger methods. A user-configurable grace period before automatic deletion is nice, as it allows to eventually use the number of downloads in statistics, if the file downloads are not happening from the default files folder.

I’ll have to refine the mechanics a bit [edit jrp: for v. 0.11] because I’m not sure how feasible it is, but that’s the plan. How does that sound?

=> Thank you again for the detailed answer. Can’t wait for 0.11. Only need to fix the link issue…

Last edited by jayrope (2011-07-20 12:47:47)

jayrope · 2011-07-20 13:26:09

What about the option to use an existing asy_jpcache key as a (part of a) key for smd_access_keys?

I’m still thinking, what kind of functionality this could implicate, however, deletion times for both plugins could be synced, when necessary.

Looking around in the jpcache code, will post, if i find something of use.

Reminds me: What happened to smd_remote_file / smd_secure_file ? Found this mentioned here.

Bloke · 2011-07-20 13:30:49

jayrope wrote:

the original file path remains visible within the generated path.

Yes. smd_access_keys does not obfuscate links.

i get a 404 on direct access of this link whilst the mp3 player says “file not found”. Rrrr.

Right. I should explain better. The access key you create is only useful in two situations:

to protect a Txp /section/article (or, in 0.11+, /section URLs are permitted)
to protect Txp file_download URLs

The key itself is just a string of junk: it doesn’t protect the resource itself. That’s the job of <txp:smd_access_protect>. If your musicalities section existed in Txp you could wrap your page content with <txp:smd_access_protect force="1"> tags and then nobody could gain access to it without a key that was generated for that URL.

At the moment, you are trying to protect a resource that is outside Txp’s control so nothing is working. Txp needs to be in the loop somehow. Two ways you can do this with non-web-accessible content:

Method 1

Move musicalities out of webroot
Set the location of your File path (in Advanced Prefs) to the musicalities dir
After uploading your files to that protected area, go to Txp’s Files tab, and under the ‘Existing files’ dropdown, select the file you uploaded and create a real Txp file_download URL for it
Use that site.com/file_download/N/file-name.mp3 as your URL to protect in smd_access_keys

Benefits of that approach:

The real URL path is obfuscated for you as it’s ‘covered’ by the /file_download URL structure
Since the dir is out of web root, no direct access is possible — no need to worry about .htaccess

Method 2

Create a Txp section from which to serve your audio content
Inside your page template (in v0.11, which you can have now if you like: I’ve got one thing to add which isn’t critical) or inside an article in that section (for v0.10) you can put <txp:smd_access_protect> tags around your jnm_audio tags
In the unprotected part of the Page/article, you can put <txp:smd_access_key> tags which allow people to create access keys to the article itself (it’ll do this by default without the url= attribute)
The clever bit is that you can set the trigger to be, I dunno, the ID of the file itself, or part of its name, or whatever — this info can be obtained inside a <txp:file_download_list> tag fairly simply. Thus your URLs might look like this: http://domain.com/protected/access/1/5bdbc2abd391174b397dea9b1e207bd8c2cdb092/4e26b80d (the /1/ is the file ID)

You can probably protect each jnm_audio individually by doing this:

<txp:file_download_list>
   <txp:smd_access_protect trigger='<txp:file_download_id />'>
      <txp:jnm_audio blah blah />
   </txp:smd_access_protect>
</txp:file_download_list>

Not sure if that’ll work, but it might. Failing that you can just generate an access key for the entire article and wrap all your jnm_audio tags inside it: one key to rule them all :-)

Further, if you also shift the musicalities dir out of web root, it doesn’t matter if your jnm_audio tags all reference them directly (as files, not URLs of course, since that will fail) because nobody can access them from the web.

I haven’t looked at radioartnet but I’ll take a gander and see if I can offer obfuscated URLs in a future version.

If mp3 files are very long, they will probably still play from the browser buffer provided they downloaded to the player within the time limit.

Yeah, I expect the access key only cares about the resource at the start of the download: if it takes a week to stream, it shouldn’t care.

Bloke · 2011-07-20 13:33:47

jayrope wrote:

What about the option to use an existing asy_jpcache key as a (part of a) key for smd_access_keys?

I’ve no idea about asy_jpcache. Never used it. But if you can get at the key you can use it as a trigger or inside smd_access_key’s attributes via tags-in-tags. Interesting to know if it works. Thanks in advance for any insight.

What happened to smd_remote_file / smd_secure_file

Remote file is still alive and (barely) kicking. I got partway through smd_secure_file and decided on smd_access_keys and smd_ipn as a better approach because it’s not just limited to files. Currently the other plugin is sitting on the shelf gathering dust.

Last edited by Bloke (2011-07-20 13:36:06)

sacripant · 2011-07-21 17:20:17

Hi Steve,
I continue my tests, but I’m slowed down by some strange behavior of context category.

jayrope · 2011-07-25 12:45:04

Hi Stef, same here, am slowed down by having to work on another project. However, i implemented your last suggestions and they did help a lot. Unfortunately i ran into a totally different issue, which mainly has to do with sending out the proper mime-type headers on access-keyed mp3. Will have to analyze that in detail however. It is possible, that jpcache was the originator of the problem. More later. Thank you!

sacripant · 2011-09-20 18:49:25

Hello Steph,
My feedback for smd_access_key 0.11. Better late than never

the requirement

The user must provide documents to some of these clients. 1 or 2 times a year. No more.
The client does not need a login and password to access just a once a year on a site to download some documents.
So I chose the principle of access keys.

For the user

Create a file category with the name of his client.
- This category should be stored as a child of the category “private”.
- He can create as many customer category they want.
Import the files to be transmitted in the category
Generation of the access key only from the back office and transmitted to the client by mail.

To simplify the process for the user, I searched for a solution that is always the same url (url of the category private) and the trigger is the name of the category (ie the client).

url : site_url/category/file/private/
trigger : category name

1st problem: the translation of urls for categories.

In French, the URL is
site_url/catégorie/file_context/fichiers-prives
But this url does not work and returns a 404 error
We must replace the é with %C3%A9
site_url/cat%C3%A9gorie/file_context/fichiers-prives

This is a bit complicated to explain to my client.

The file “lang FR” has been updated a few days ago and now the url is:
site_url/catégorie/fichier/fichiers-prives
This update may cause redirect problems… I should explain that to my client…

2nd problem: the display of errors (smd_access_error)

I think the plug’in was not designed to operate in a loop category.

<txp:category_list type="file" parent='<txp:category />' exclude='<txp:category />' break="" >
	<txp:smd_access_protect expires="172800" trigger='<txp:category />' force="1">
		<txp:file_download_list category='<txp:category />' sort="created desc" limit="999" break="" />
	<txp:else />
		<txp:output_form form="access-keys-errors" />
	</txp:smd_access_protect>
</txp:category_list>

Whatever the trigger used in the url (the first, second, third loop) is always the output_form “access-keys-error” of the first loop will be used.

For the good output_form be used with the good trigger, I had to juggle with variables (it’s understandable? not sur).

My code (certainly crooked but it works)

cat_list:

<txp:category_list type="file" parent='<txp:category />' exclude='<txp:category />' break="" >
	<txp:smd_access_protect expires="172800" trigger='<txp:category />' force="1">
		<h2 class="clear"><txp:category title="1" /></h2>

		<txp:variable name="maximum" value='<txp:smd_access_info item="maximum"/>' />
		<txp:if_variable name="maximum" value="0">
			<txp:variable name="max-value" value="∞"/>
		<txp:else />
			<txp:variable name="max-value" value='<txp:smd_access_info item="maximum"/>' />
		</txp:if_variable>

		<p>Cette clef d'accès expirera le <strong><txp:smd_access_info item="expires" format="%d %m %Y à %H:%M:%S"/></strong> <br />
			Nombre de connection(s) autorisée&nbsp;: <strong><txp:variable name="max-value" /></strong> <br />
			Nombre de connection(s) enregistrées&nbsp;: <strong><txp:smd_access_info item="accesses"/></strong> </p>

		<txp:variable name="style" value="last" />
		<txp:file_download_list category='<txp:category />' sort="created desc" limit="999" break="" />

		<txp:variable name="error" value="yes" />
	<txp:else />
			<txp:output_form form="access-keys-errors" />
	</txp:smd_access_protect>
</txp:category_list>

output_form ‘access-keys-errors’:

<txp:smd_if_access_error type="smd_akey_err_expired, smd_akey_err_limit, smd_akey_err_bad_token, smd_akey_err_missing_timestamp">
	<txp:variable name="keys-error" value="yes" />
<txp:else />
	<txp:variable name="keys-error" value="no" />
</txp:smd_if_access_error>

<txp:if_variable name="keys-error" value="yes">
	<txp:smd_if_access_error>
		<h2 class="clear">Erreur <txp:smd_access_error item="code"/></h2>
		<txp:smd_if_access_error type="smd_akey_err_forbidden">
		   	<h3><txp:smd_access_error item="message" break="br" message="L'accès à cette page est vérouillée."/></h3>
		<txp:else />
		   <txp:smd_if_access_error type="smd_akey_err_expired, smd_akey_err_limit">
		      	<h3><txp:smd_access_error item="message" break="br" message="Votre clef d'accès a soit expiré soit atteind son nombre de connexion maximum"/></h3>
			<txp:else />
				<txp:smd_if_access_error type="smd_akey_err_bad_token, smd_akey_err_missing_timestamp">
			      	<h3><txp:smd_access_error item="message" break="br" message="Votre clef d'accès n'est pas conforme, vous ne pouvez accéder à cette page"/></h3>				
				<txp:else />
					<h3>Une erreur s'est produite pour accéder à cette page</h3>
				</txp:smd_if_access_error>	
		   </txp:smd_if_access_error>
		</txp:smd_if_access_error>
		<p>N'hésitez pas à <a class="go-contact" href="#contact">nous contacter</a> si vous avez un problème pour accéder à vos informations</p>
	</txp:smd_if_access_error>
	<txp:variable name="error" value="yes" />
</txp:if_variable>

mrdale · 2011-09-20 20:43:12

Hi Stef,

Been meaning to ask.

Could this plugin be used to handle gift-certificate or coupon-code style functionality?, ie code, displays content once only, then the content is no longer available to that user?

jakob · 2011-09-20 21:17:12

@Dale, yes it can :-) The access key URL is a long string but you can set either access duration or number of accesses. After that the resource is no longer accessible.

mrdale · 2011-09-21 01:28:51

jakob wrote: …access duration or number of accesses. After that the resource is no longer accessible.

…but not per user/viewer, right?

jakob · 2011-09-21 07:40:57

As far as I understand it (only used it once so far), you can issue many access keys for a single resource, so providing each user is given a unique coupon (access key), you can do that.

If you mean a single coupon code that is given to many people, each of whom can use that same coupon code once, I don’t think that’s possible (but I could be wrong).

Bloke · 2011-09-21 10:16:50

sacripant wrote:

the translation of urls for categories.

Thanks for the detailed feedback: it really helped get straight to the problem.

This issue is actually the reason behind both your issues. I forgot to decode the URL from its percent-encoded state so it never matches the actual URL. If you try the new beta I’ve just uploaded, site.com/catégorie/fichier/private/client1/{token}/{timestamp} URLs should now work fine. Please let me know how you get on and if there are any more oddities.

btw, in doing this fix I also noticed two things:

When creating a new key from the admin side you get a white screen. Fixed
There is no way to generate section_mode URLs from the admin-side. Not fixed (yet).

mrdale

jakob is right: each generated URL token is unique. To implement gift cert(ish) behaviour you can either:

Generate an “open” certificate, perhaps time-limited, and issue it to as many people as you like
Do (1) but limit it to the first ‘N’ people who use it
Generate a single-use certificate on-demand and send one to each person. Once used, game over

Once you smd_access_protect the destination page given in the URL you can validate the token and apply some transform like “price CF – 20%”. The thing to remember is that an access token protects a resource (Txp URL / file) so it’s not a true coupon code like “MRDALE-MEGACODE-10293847” that you can pass around and use in some other form.

FYI, option 3 can be generated in the Thanks Form of a zcr after you’ve nefariously ferreted away someone’s personal details, or after a successful PayPal transaction via the as-yet unreleased smd_ipn plugin.

Last edited by Bloke (2011-09-21 10:18:41)

mrdale · 2011-09-21 14:44:04

Hrm… very interesting… must cogitate.

Theoretically, all it would need to track per-user use is a field that would collect user IDs and a way of concatenating a user ID# to that field on access…

curiouser and curiouser.

This is a ingenious little plugin. You’re a right clever limey, encha?

Bloke · 2011-09-21 15:01:04

mrdale wrote:

Theoretically, all it would need to track per-user use is a field that would collect user IDs and a way of concatenating a user ID# to that field on access…

Check out the extra attribute then, and see example 3 in the help. You can pack arbitrary content into the key itself and then extract it on access.

husainhk · 2011-09-25 11:29:44

Hey all, anybody made this work with zem_contact_reborn? I haven’t started playing with the plugin yet, but would like to know if any special set up is required.

I am aiming for the user to provide a name and an email address, before allowing access to a page, which will be available as a redirect after the form is submitted.

Many thanks!

Textpattern CMS

Textpattern CMS support forum

#16 2011-07-20 12:46:07

Re: smd_access_keys: secure, limited access to content

#17 2011-07-20 13:26:09

Re: smd_access_keys: secure, limited access to content

#18 2011-07-20 13:30:49

Re: smd_access_keys: secure, limited access to content

#19 2011-07-20 13:33:47

Re: smd_access_keys: secure, limited access to content

#20 2011-07-21 17:20:17

Re: smd_access_keys: secure, limited access to content

#21 2011-07-25 12:45:04

Re: smd_access_keys: secure, limited access to content

#22 2011-09-20 18:49:25

Re: smd_access_keys: secure, limited access to content

the requirement

For the user

1st problem: the translation of urls for categories.

2nd problem: the display of errors (smd_access_error)

My code (certainly crooked but it works)

#23 2011-09-20 20:43:12

Re: smd_access_keys: secure, limited access to content

#24 2011-09-20 21:17:12

Re: smd_access_keys: secure, limited access to content

#25 2011-09-21 01:28:51

Re: smd_access_keys: secure, limited access to content

#26 2011-09-21 07:40:57

Re: smd_access_keys: secure, limited access to content

#27 2011-09-21 10:16:50

Re: smd_access_keys: secure, limited access to content

#28 2011-09-21 14:44:04

Re: smd_access_keys: secure, limited access to content

#29 2011-09-21 15:01:04

Re: smd_access_keys: secure, limited access to content

#30 2011-09-25 11:29:44

Re: smd_access_keys: secure, limited access to content

Board footer