Feature Request -- Allow using your own IDs

[turnerd10]

My request is to allow the ability to make ones own shorty_id instead of the generated one.

Now to check if one is used it could be placed in some sort of database and checked to see if it was there.

And if a user deleted that certain one, only the user that created it could add it again.

Maybe changing a value of itself in the database as to being "deleted" but already used. Have it redirect to a 404 of some sort if "deleted"

Limiting the length of the id might also be a factor, or how many a user can use.

[blahgeek]

+1 this would be very useful

[blahgeek]

@turnerd10 I've forked this repo and added this feature, see https://github.com/blahgeek/shorty

[arkascha]

Hey, great someone finally addresses this issue. Contributions to these apps are really welcome. So I am looking forward to your results!
I do understand that you just started with this. Once you feel fine with it I'd love to receive a pull request for this feature. Maybe you could make a short sketch before about how you want to implement such feature? I assume that others are most interested in how you want to make such feature available for the different backends. Or maybe how you want to block it for all backends except for the internal 'static backend'.
Anyway, such contribution is good news! Keep working on this!

[arkascha]

@blahgeek: any news?

[Phr33d0m]

As we discussed with @arkascha on IRC, this could be done in a way that doesn't disturb the current URL generation[1] and functionality[2]. This is a resume of (what I believe will be) the best way of implementing this issue, either for anyone that wants to help implementing it or just for me if I have some free time in the future to do it.

Introduction

Here are some details. If the user wants to generate a shorty URL he could:

• Just use the default generated ID.
  • URL: public.php?service=shorty_relay&id=randomID
• Use his own personalized ID in which will result in:
  • URL: public.php?service=shorty_relay&id=customID&user=someUser

Functionality

2 different URLs?? OH NO!

Yes, having 2 different URLs might be a problem if we're using some RewriteRule. For that reason, the service should always accept a user= parameter. I can't think of any other reason not to like this (unless that... the url gets too long?).

• When it's empty (i.e. user=) or not specified we assume the ID is a random generated one. So the following 2 URLs have basically the same functionality.
  • URL: public.php?service=shorty_relay&id=randomID
  • URL: public.php?service=shorty_relay&id=randomID&user=

That way, users can keep using the same URL syntax as before which agrees with what I said before ([1]). And people can still use only 1 RewriteRule, for example:

RewriteRule ^/go/([A-Za-z0-9]{4,16})/?([A-Za-z0-9])$ http://domain/owncloud/public.php?service=shorty_relay&id=$1&user=$2 [L]

• URL: /go/randomID => public.php?service=shorty_relay&id=customID
• URL: /go/customID/someUser => public.php?service=shorty_relay&id=customID&user=someUser

People can customize this to begin with username (which I prefer):

RewriteRule ^/go/(?:([A-Za-z0-9])/)?([A-Za-z0-9]{4,16})$ http://domain/owncloud/public.php?service=shorty_relay&user=$1&id=$2 [L]

• URL: /go/randomID => public.php?service=shorty_relay&user=&id=customID
• URL: /go/someUser/customID => public.php?service=shorty_relay&user=someUser&id=customID

Or something like that... I'm really bad with RewriteRules

Issues

Security

@arkascha mentioned several times that this might create some security (or better said: a privacy) issue. We can't control how users are going to use the system. We're limited to offer the functionality (yet it must be secure from our end).

When a user creates a custom ID for a public shorty, for example, named "passwords" where he stores all his websites/system passwords (which can be accessed via public.php?service=shorty_relay&id=passwords&user=stupidUser) - there's nothing we can do about it, can we?

If we ignore the above described case, everything should be secure enough depending on what 'word/phrase' the user choses for his customID (if it's easily guessable for example) and the content he's sharing.

Also, the user is always offered the default random generated ID which shorty already uses[2].

Implementation

@arkascha mentioned that there might be a problem implementing all this without breaking the rest of the backends.

[arkascha]

@Phr33d0m: thanks for condensing our exchange!
Some additional remarks from my side:

1.) the Shorty keys are not random at all, that would allow collisions. But this details does not have any effect on your thoughts, so we can just ignore it here...
2.) the problem with adding the user id to the shortened url is indeed, as you pointed out yourself, that the generated url becomes longer. That is something not acceptable for this kind of app: the main purpose is to shorten urls. For many users each additional character is a pain, since they type the urls into smartphones for example. There are complaints about shorty keys being to long, that other shorteners use only 6-7 chars instead of Shorty using up to 11 chars. I think this aspect is valid. Also when posting links inside email messages and the like shortness is important to keep links from getting broken by stupid email clients not supporting wrapped links and the like. So I am afraid extending the length of generated urls not an absolute no-go.

If this results in not being able to add the users identity to the generated url then the main objection against such custom keys is a security/privacy issue. I am not at all concerned about shortened urls being guessed by attackers. Shortys are generated to be published, so relying on a non-guessable url is plain stupid. If users rely on the cryptic keys to protect their content then I absolutely agree with you that this is not our problem.
But there is another thing: custom keys typically result in meaningful strings like 'document', 'application', whatever. These are frequently used expressions thus there is a high risk of reuse. This leads to collisions between Shortys. Certainly the app can easily prevent to use a given custom key a second time (collision detection). however this is not possible for Shorty that have been deleted in between. Shorty has no memory for such keys, since deleting a Shorty finally removes it from the database. As a result the generated url would come out the same as some Shorty generated long ago. Shortened urls are typically generated to be posted to message boards, web pages and the like where you cannot really remove them again. Currently delete Shortys only result in such posted links being broken (which is fine since there is a reason why you delete the Shorty, you WANT to break access to the target). However if a new Shorty gets generated using the same custom key then suddenly that onld, previously broken Shorty gets reactivated again! It can be resolved again, though pointing to another target! This without the knowledge of the user generating the new version of the Shorty. Again in my eyes this is a no-go. So one used custom keys would have to be remembered (and thus blocked) forever by Shorty to prevent this privacy thread. This certainly is possible from a technical point of view, but things get pointless when all the self explaining and easy to remember strings are gone and cannot be reused. So the users start to block themselves after some time...

I'd love to see this feature implement somehow, but currently for me the disadvantages, threads and open questions simply outweight the feature and easy of use.

About this feature breaking the use of other backends? Not sure actually, depends on the implementation. It certainly would make the implementation, the dialogs and thus the usage more complex which is not desirable. I'd say it boils down to having a more dynamic dialog which relects the features of the backend currently in use by the user. This is kind of ugly, since it breaks the currently clean abstraction of the backend. But it should be possible.

So sorry if I break things down here. But for me the questions are not yet answered. And I hesitate to implement such feature with unanswered questions and issues....

[arkascha]

I finally came up with an alternative approach that looks quite elegant to me: a second plugin called 'Shorty-Alias' (there already is the 'Shorty-Tracking' plugin for Shorty). If enabled, it should allow to define a user specified alias which will indeed result in a second url to access a given Shorty, jut as Phr33d0m suggested above.
Such an Aliases will be stored in a separate database table. Because we are talking about an optional plugin it would be very painful to alter the existing table structure for this. This allows to change a given Alias at all times if desired. Never ever a once used Alias term will be removed from that table. It might be that the Shorty itself is deleted, so that an Alias points into Nirwhana, but that will only result in a sense making 404 error (not found). But not ever deleting a once defined Alias will reliably prevent the collisions by reusage I wrote about above. Collisions caused by the overlapping namespaces of Shorty Ids and Aliases can be prevented by using a second rewriting rule. That way Shorty will know whether a requests refers to a Shorty by its Id or by an Alias.

Unfortunately I cannot invest time into this right now. Maybe someone else will give it a try?
Shortys plugin interface will have to be extended for this. Also one has to find a clever solution to extend the existing dialogs on the fly.