Public sharing and pretty URL

[fossxplorer]

Hi,
it would be benefical for oC to have prettier URL for shared links. Currently it looks like http://example.com/public.php?service=files&t=659082f5a8a1ab14a19ce3fd0cfc6720.
DropBox' equivalent looks like https://www.dropbox.com/s/e12pt647unyo3a8/myfile.ogg.

One suggestion might be to get the URL on the form http://example.com/public.php/files/t/659082f5a8a1ab14a19ce3fd0cfc6720/myfile.ogg as public.php might be part of the core logic in oC.
Do also note the file name being displayed at the end of the URL. Please do not encapsulate the file name in the token as there are cases where this might help, e.g to be able to search among many bookmarked publicly shared links!

I would like to use the opportunity to thank all the devs behind oC!

@butonic @bartv2

[butonic]

@bartv2 we could add a route for public shared files. they could contain the filename but actually use the token. This is related to #553 where I stell need to figure out a good way to generate links with the router when browsing shared files. we could use something like http://example.com/t/659082f5a8a1ab14a19ce3fd0cfc6720/myfile.ogg the filename could just be ignored ... or we could use the part after the token to denote the folder and file when browsing a shared directory. sth like http://example.com/t/659082f5a8a1ab14a19ce3fd0cfc6720/some/sub/folder/myfile.ogg
@MTGap what do you think? we should come up with clean sharing urls for oc5.

we could also use all characters and not only a hex hash to shorten the url

[fossxplorer]

Additional enhancement suggestions:

1. For publicly shared file we could have the URL on the form http://example.com/t/659082f5a8a1ab14a19ce3fd0cfc6720/myfile.ogg as commented by @butonic
2. For publicly shared folder we could have the URL on the form http://example.com/t/659082f5a8a1ab14a19ce3fd0cfc6720/ as it's relative to the shared folder.
3. For shared folder or file with password protection we could have URL on the form http://example.com/t/659082f5a8a1ab14a19ce3fd0cfc6720/ in order to disclose less information in URL.

[MTGap]

@butonic Well the links are broken in the filesystem branch, which I can't understand why. Preferably any work on public links should be done there in the filesystem branch to ease merging.

I'd rather not get involved in this whole link structure again.

[fossxplorer]

Hi, will there be any chance to get this implemented for OC 5?
@butonic @bartv2

[karlitschek]

We are already in feature freeze. So improvements here have to wait for ownCloud 6

[jancborchardt]

A similar issue are the links for CardDAV and CalDAV which are a real pain to put in on mobile. (cc @msrex)

Is there no way to have routing (or whatever it’s called) so I just need to put in owncloudprovider.com as the address and it will get consolidated? If it needs an additional PHP module, then we should recommend that as optional module and enable awesome short URLs for when the server supports it. I see no issue (for user experience) in having differing URLs when the servers are different.

[jancborchardt]

oh and cc @georgehrke and @tanghus about the *DAV urls.

[jerrac]

Any work being done on this? It would be much better to have something like owncloud/public.php/username/subfolder/file.ext than what's currently generated. It would certainly make my life easier as I look into migrating from a simple sftp server to owncloud....

And http://www.not-implemented.com/urls-are-for-people-not-computers/ has some good points. I look at the url's of links I'm clicking all the time to make sure they're good ones.

[m3nu]

We have been discussing this issue at #2467 as well. Rewrites would be easy to do. The main issue from my point of view is URL generation without breaking non-rewrite servers. Is there a test, if rewrites are enabled yet?

This should be a top-priority for v6, along with simple Cal/CardDAV configuration. The old DAViCal worked with iOS by just entering server.com or cloud.server.com

[jancborchardt]

@manuelRiel as you suggested in #2467 (comment), it would be cool if you can check how to do that best and then submit a pull request. And I totally agree that it should work simply by entering server.com and get the Cal/CardDAV from there.

[jerrac]

Reading through #2467, it looks like the token would still be used. Maybe with the filename, maybe without. So, the only thing that would really improve is we wouldn't have the public.php string.

That's somewhat better, but still pretty ugly.

Why was the decision made to use tokens for shared files, rather than something like /username/folder/filename.ext?

I have no idea how the app system works, but would it be possible for an app to provide aliases to the tokenized urls?

[jancborchardt]

@jerrac the decision was made (as far as I know) because usernames can change, and file names and locations can also change. But share links shouldn’t break just because you move your stuff around.

[jerrac]

@jancborchardt That makes sense. Kinda like how Drupal has a node number for every page that never changes.

So, thoughts on how hard it would be to make an app that does what I want? Aliases the ugly token link to a clean url? That's what Drupal does.

[dustinlw1987]

I wonder if there's a way to include YOURLS functionality - it is open source, has no risk of "disappearing" like most URL shortening services.

[jancborchardt]

Closing for reasons above: Because usernames can change, and file names and locations can also change. But share links shouldn’t break just because you move your stuff around.

[cweiske]

@jancborchardt: I don't see why you close this issue ("shorter urls for shared content") because usernames can change.

All I want is to have a shorter URL than https://myowncloud.example.com/public.php?service=gallery&t=0351cafbc6f68578e7b65sbfaab03596 - for example https://myowncloud.example.com/g/0351cafbc6f68578e7b65sbfaab03596.

There are no information in there that change.

[BeecherNetworks]

Another vote in favour of reopening please. With respect, the reason for closing is spurious -- if the file is still there, the link can still point to it, the username and filename or location are irrelevant. And even if the share link does break, that's the user's/admin's lookout. The lnternet is littered with linkrot, it hasn't broken.

[BeecherNetworks]

Excellent!

[jerrac]

Couldn't https://myowncloud.example.com/g/0351cafbc6f68578e7b65sbfaab03596 be done via apache rewrites?

I still think some kind of alias system would be good. The let admins and users figure out how to deal with changed aliases. That's what we do on our Drupal site, and it works well.

[resurrectedstar]

For those who are bored, and just want it to work in nginx, add the following to your '/' location block.

rewrite ^/f/(.*)$       /public.php?service=files&t=$1;

Then, http://yourowncloud.com/f/keyhere will work :)

But back on topic, really
I agree that we should have alias support - allows users to customize them at will. They can just add a rewrite like the one above, and the url will look better.

[DanielRuf]

+1

[jerrac]

Any thoughts on aliasing? We recently soft-launched our OwnCloud instance at work, and some of the feedback has been related to how the share url's work. Specifically, that people want to be able to user example.org/users/username/sharedfile.ext style links, and that the current url's are unwieldy.

I wouldn't think it would be too hard to implement an alias feature. I think it would be something like a table listing normal share links as a key to the user generated alias, plus some checking to make sure users don't try to use aliases that another user has already generated. Then add checking the alias table into however OwnCloud routes urls.

If I ever get the time to work on this I will, but that doesn't seem likely to happen anytime soon considering my current and forecasted workload... Unfortunately, there hasn't been enough user feedback on this for me to get assigned to fixing it. :/ If anyone wants to tackle this, I could justify making some time to help test.

[timeggleston]

+1

[nqoliv]

Hi all,

Does anyone knows if shorter sharing urls will be add to Owncloud 7 features in a near future?

I really need this feature.

[Niduroki]

With #10755 we got links like https://yourcloud.com/index.php/s/tbzID5QMCYhtVOs now.
When #5744 is done these will become https://yourcloud.com/s/tbzID5QMCYhtVOs

Closing this thus.

[ghost]

Why did you close this @Kondou-ger your example are not pretty urls at all a pretty url might be something like https://yourcloud.com/s/bjork-mp3s or https://yourcloud.com/s/meeting-minutes2014 or something but https://yourcloud.com/s/tbzID5QMCYhtVOs is absolutely not pretty or easy to remember.

[Niduroki]

@bkerensa urls like https://yourcloud.com/s/tbzID5QMCYhtVOs/myfile.ogg are being worked on somewhere.

Self defined urls like https://yourcloud.com/s/kondous-pdfs are a different thing, but I don't think we even need them, since you are not supposed to remember these but send them via chat/email/…, and click on them, not type them in.

For someone who isn't tech-savvy typing in the whole yourcloud.com/s/something might already be challenging enough from my experiences.

@butonic @DeepDiver1975 @jancborchardt opinions?

[jerrac]

@Kondou-ger

since you are not supposed to remember these but send them via chat/email/…, and click on them, not type them in.
I disagree. URLs are also a way to know where you are. If making them readable isn't important, then why do we have DNS? Why not just use ip addresses?

Here's another use case. If you are hosting a lot of public files that you want search engines to index. Yes, OwnCloud might not be the most efficient method, but if you have it implemented already, why not? For search engines, having a solid pretty URL is important. That's why most Drupal sites use the PathAuto module to change node/number into blog/this-is-my-title.

Or maybe you are printing a url in a snail mail newsletter? site.com/jerrac/file.jpg is far quicker to type than even a url shortened url, since you don't have to keep double checking that you typed the right sequence of letters and numbers.

Basically, there are use cases for pretty urls. I'm fine with closing this topic if the OwnCloud devs think it's not a feature for core OwnCloud. But don't close it as fixed. Fixed would either be it actually getting into OwnCloud, or someone successfully building an app for it.

[ghost]

Why wouldn't we want to remember a link? Dropbox and Box have offered this for years now (self defined URLs)

Use case: I run a non profits IT and we post all our documents in Owncloud as we have to keep records long term we think link to share links from wordpress to things like minutes and financial records. We keep years of records.

Having to guess whether s3Ks7kAfjsj is the hash URL for our 2013 finance records versus a nice clean self defined named URL is a breathe of fresh air.

Its also the reason we created DNS versus just using IP addresses for websites... People can't remember strings of numbers.

[ghost]

If we can't seek to be an open source solution that seeks parity with priority cloud platforms then why continue? Even the enterprise edition should have this

[BeecherNetworks]

+1 for readable URLs.

[Niduroki]

@jerrac @bkerensa @dahamsta that's just my opinion. Let's see what other devs say about this.

[jancborchardt]

Something like myowncloud.com/[some user ID]/that-document.odf would be great indeed. And yes, that’s how Dropbox URLs look like. I don’t know of the technical or security implications though.

@DeepDiver1975 @LukasReschke your takes please.

[BeecherNetworks]

Dropbox uses a userid rather than a username. Ideally I'd like the option of both, with the userid being the default.

https://www.dropbox.com/s/vpqym5e0saf43bt/.nomedia?dl=0

[LukasReschke]

Something like myowncloud.com/[some user ID]/that-document.odf would be great indeed. And yes, that’s how Dropbox URLs look like. I don’t know of the technical or security implications though.

That would be possible. Though the [some user ID] is actually a share ID and NOT an user id as this leaks some information you don't necessarily want to leak at this point.

The "Show raw file" feature will not be possible at the moment without having another domain support.

[jancborchardt]

@LukasReschke yeah, that sounds fine. The important thing here is that there is some human-readable part in the URL, in this case the filename.

[jerrac]

What about user configurable aliases? Say, my user name is blah, but I
configure my share url to be foo/subdir/filenam.ext.

--David Reagan

On Tue, Mar 3, 2015 at 6:52 AM, Jan-Christoph Borchardt <
notifications@github.com> wrote:

@LukasReschke https://github.com/LukasReschke yeah, that sounds fine.
The important thing here is that there is some human-readable part in
the URL, in this case the filename.

—
Reply to this email directly or view it on GitHub
#1074 (comment).

[jancborchardt]

@jerrac as @LukasReschke said, usernames won’t be leaked/used anyway. Also, configurability by users is overkill here and not needed.

[jerrac]

Though the [some user ID] is actually a share ID
So, a share ID isn't a random string of characters? It would be something
human readable?

--David Reagan

On Tue, Mar 3, 2015 at 11:55 AM, Jan-Christoph Borchardt <
notifications@github.com> wrote:

@jerrac https://github.com/jerrac as @LukasReschke
https://github.com/LukasReschke said, usernames won’t be leaked/used
anyway.

—
Reply to this email directly or view it on GitHub
#1074 (comment).

[LukasReschke]

The Share ID will be random. The filename however the file was called. We will not add a custom URL function at the moment for multiple reasons (including the risk of social engineering etc.)

If you really want URLs that look like you want please use a URL shortener :)

[ghost]

Clearly other cloud storage platforms dont think the risk of social engineering is high.

[LukasReschke]

1. We are not others. We are we ;)
2. Honestly this discussion is useless we can spend time better instead of an endless discussion. If you really want it that way you are free to write an ownCloud app that behaves tjid way.

=> Locked.

[MorrisJobke]

Fixed in 9.0 #14081