Jump to:
| Project: | Short URL |
| Version: | 6.x-1.2 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | gansbrest |
| Status: | patch (to be ported) |
| Issue tags: | onetime url |
Issue Summary
Hi.
Couple words about the intentions behind creating this patch:
I was using default drupal 'forgot password' functionality to send an email with one time link, which you could use to reset your password.
The problem is the link is way too long and some mail systems truncate that url which breaks password reset process. I decided to use this module to generate an alias for those long 'reset' urls and I used hook_mail_alter to find that email by id and change the url inside of it (might be useful for someone).
Since 'reset' url can be used just once, I didn't want to keep those urls in shorturl_link table, so I added new field called 'onetime' which basically says if this is one time url or not.
Then I modified .module and .install file a little bit to take care of new flag (patch files are attached).
The only problem I encountered while producing this patch is creating new entry inside .install file. I decided to use db_add_field, assuming it will give me an option to use drupal_write_record in the module (because the author was used it initially), but for some reason it just didn't want to save my new field. So I replaced drupal_write_record with regular db_query(). If anyone have any idea why it didn't want to save in the first place, I would be glad to modify the patch.
| Attachment | Size |
|---|---|
| shortModule.patch | 3.12 KB |
| shortInstall.patch | 570 bytes |
Comments
#1
Not sure why you need to delete these URLs. The destination URLs should be the ones that get invalidated, not the redirect URLs.
Deleting entries from shorturl_link is a records management violation: generally things should get invalidated rather than being deleted. But since the destination URL is invalid anyway (or should be), I am not sure why should ShortURL check something this specific/redundant.
#2
I think better solution would be creation 'expire' field instead of onetime field and store link expiration timestamp.
(0 - permanent link, timestamp - expire timestamp).
Then on the cronjob (by implementing hook_cron) we can remove expired entries (expire <= current timestamp)
That way there will be a possibility for garbage collection, which might be useful for large websites with a lot of temp links created every minute (let say for unpaid customers). Otherwise the shorturl_link table will grow very quickly.
Theoretically you should invalidate both links, short and source. But source link invalidation might be done without storing/updating data in the database, when short link will be always stored in db (and will remain there forever without garbage collector).
If the link will be deleted from short_link table, then there will be 404 page displayed which should take care of explanations about what happened to this link ('Page not found. The content of the page was removed or the link was expired')
#3
I think you are mixing two requirements. Time-expiring links and one-time-only links are not equivalent. Maybe complementary, but clearly two different use-cases.
If they were to be implemented, a column should do it (in both cases), not - brute-force deletion of a row in the database, though - yes.
For the one-time links (the original use-case you described) I still think the destination URL should expire. Expiring short URL is false security. If destination URL expires, short URL will redirect to 404, return 404 and use-case will be specified, so there's little need for this use-case.
As for time-based expiration, I am not against it, but since I don't no major URL shorteners that implement this feature, I don't know a use-case in Drupal specifically where it is useful, so I am not sure about the need. If you can describe an important use-case, that would help, please.
Thank you