|
Re: Expire URL (SHA1)
by tye (Sage) on Dec 30, 2015 at 19:00 UTC
|
You encode the expiration date into the URL and then add a cryptographic signature (by computing something like the SHA1 of the data in the URL plus some string that you keep secret).
| [reply] |
Re: Expire URL
by Your Mother (Archbishop) on Dec 30, 2015 at 22:25 UTC
|
In addition to what tye suggested—this is how places like Amazon do it for services, see the methods and guts of URI::Amazon::APA—you can do a GUID with something like Data::UUID and cache it (best if this is for an authenticated user) with its expiration time with one of the backends to CHI. Caching has the benefit of being self-managing while the signed URI approach is more… robust (if you do it right)? Professional? If it’s a free service or something, I’d cache, if it’s a paid service or something, I’d do the hashed/signed URI.
| [reply] |
|
|
The main difference for me is whether or not you have to use server-side storage. This leads to also needing to implement cleaning up the storage, which can be even more complex. You may also need to deal with monitoring storage capacity perhaps only to prevent denial-of-service attacks.
while the signed URI approach is more… robust (if you do it right)?
Actually, using server-side storage is probably more secure(?) despite not using cryptographic algorithms. When using the signed URL pattern, you will eventually need to implement generation numbers where each generation uses a different secret string. This allows you to deal with the secret string being suspected of no longer being secret. Just doing that on a regular interval may be a good idea if you want to be serious about this (but that then requires that you come up with a cryptographically secure random string generator and a secure method for distributing the new strings -- security is hard).
If it’s a free service or something, I’d cache, if it’s a paid service or something, I’d do the hashed/signed URI.
I don't see how one is more professional than the other. If I already had handy a server-side session cache that auto-expires (especially if I was already using it and so was not adding a new denial-of-service point), then I might go with cached GUIDs.
At $work we mix the two. The auto-expire cache holds the details and the only data in the URL is the signature. The signature serves as the key to get the details from the cache. Just signing the URL is much simpler to implement. But hiding the details so that they don't appear in the URL seemed more "professional". (:
| [reply] |
Re: Expire URL
by Anonymous Monk on Dec 30, 2015 at 18:57 UTC
|
for my $url ( @urls ){
if( is_expired( $url ) ){
makeUnavailable( $url );
}
}
so trivial
if( is_expired( $url ) ){
return redirectForbidden('home');
} else {
return thePage( $url );
}
}
| [reply]
[d/l]
[select] |
Re: Expire URL
by hotchiwawa (Scribe) on Dec 31, 2015 at 11:32 UTC
|
Fortunately this post is not expired :D
It's a good question gt1974 (really brainstorming)
Caching is good but it creates a file on disk that can become big if you have a lot of URLs to keep or expire. If this file is removed (by you, an admin, system...), the logic will change and can be "dangerous" because the file will be recreated again (on open) and maybe filled or not (and this could be problematic). So I think that caching is not so good for this functionnality. But if you use caching, take a look at Cache::FastMmap it's really quick and easy to use.
Adding something to the url is not so good too because the user can change it and you have to manage it.
The real question is: how much URLs do you have to expire?
Why don't you just remove, rename or move the page by a job? A 404 error will be generated and could be managed by your web server. If you don't want that someone access your pages, remove it :D but maybe that you are talking about URLs to populate your pages (or db) with data (JSON...), in that case of course you can't remove them.
Peace | [reply] |
|
|
Thx hotchiwawa.. I think I will just create a process to remove the URL on the expiry date. No Need to over complicate
| [reply] |
|
|
If you use a proper caching module, especially the meta cache module CHI I suggested, you will not have to do anything manually. The cache self-manages. You just tell it when setting entries when and how they expire. And they don't have to go to the file system directly, they can be DB based, RAM based, whatever.
| [reply] |
Re: Expire URL
by Anonymous Monk on Dec 30, 2015 at 18:51 UTC
|
| [reply] |
