[TW5] Bob serving files, asking opinions

[Jed Carty]

I strongly suspect that I will regret asking this, but it is an area where feedback may be useful.

I have been working on getting the secure server version of Bob ready for an actual release where we can host wikis that have Bobs features and there need to be proper access controls so that uploaded files are only accessible with the correct credentials.

This leads to things that work fine on the server but may be a bit strange on a local version of Bob. Currently on the local version of Bob files can be served from a single folder and its sub-folders and the same files are available in every wiki. This doesn't give the desired granularity for access control so on the server version I am making it so that there is a globally accessible (assuming you have the correct permissions) pool of files which act the same as the local version of Bob, but then each wiki can also have files that have the same access controls as that wiki does.

So in effect there will be a pool of globally accessible files and then files that are accessible on individual wikis.

The problems come from how you address the files.

Currently on the local version you use a uri that starts with /files/ and then you can put in the path to the specific file you want.

My plan is to make it so that if you have a wiki called MyWiki than files specific to that wiki would be accessible using a url prefixed with /files/MyWiki/ and the files would be stored in the files subfolder of the wiki folder.

This is there there are potential problems.

In the folder where you have the globally accessible files any subfolder that shares a name with an existing wiki will not be accessible because the url would be the same as the one that points to files for that wiki.

A wiki named Foo would similarly not be able to have any files in a folder Bar if there was a wiki on Foo/Bar

These aren't significant problems on the server because due to the interface there isn't going to be much of a chance to have sub-folders, but when running Bob locally it may come up.

I don't have much in the way of an alternate suggestions other than just getting rid of the globally accessible files, but that seems like a poor choice.

Would using this be a problem for anyone, and if so why?

or let me know if you have a constructive suggestion or opinion.

[Mark S.]

A wiki named Foo would similarly not be able to have any files in a folder Bar if there was a wiki on Foo/Bar

Do you mean you can't files on /files/Foo/Bar because of the term "Bar" ? Can't it look at the full subpath "Foo/Bar", which would not match with "Bar" ?

It would be useful on laptops if there was a "local" (insecure) mode that could serve up files from anywhere like TiddlyServer. On a local machine, you often need to put resources where the space is available, rather than where some particular software wants it to go.

Thanks!

-- Mark

[@TiddlyTweeter]

Jed. Thanks for asking.

I have conceptual difficulty quite fully visualizing the difference. But I think a use case should make clear my current thought of how I envisage the physical storage of files (on disk) ...

1 - Bob "local". Example...

..\Wikis\ImagesWiki
 with subdir \img containing image files, all addressed relatively

2 - This has similar structure to Single File wiki generated by Bob...

..\singles\ImagesWiki
with subdir \img containing image files, all addressed relatively




3 - Thought of Bob Served online...

../onlinewiki/imageswiki
with subdir /img containing image files, all addressed relatively




In fact it doesn't really matter if Bob Served requires divergent placement and addressing of files per se.

The issue is rather having tools that can mass convert addressing to work whatever place you run it if that is needed.

In my simplicity I tend to prefer one method but if its essential for online to go different so be it.




Best wishes


Josiah





[Jed Carty]

Mark, you can already set the file path root to something like / and have all the files on your computer available. I have had that as an option for almost as long as I have had the local file server on it.

The problem is that if you have a wiki on Foo than when you go to localhost:8080/Foo you get a wiki. If you have a wiki on Foo/Bar than when you go to localhost:8080/Foo/Bar you get a wiki.

If you have files specific to Foo that are only supposed to be available to people who can view Foo, than those wikis are accessed using a url that starts with /files/Foo/, if you have files for the wiki at Foo/Bar that are only supposed job e visible to people who have access to that wiki they would be accessed using a url that starts with /files/Foo/Bar/

There is no way to distinguish between a file that is supposed to be associated with the wiki on Foo that is in a subfolder called Bar from a file that is supposed to be associated with the wiki on Foo/Bar

The url /files/Foo/Bar/hi.jpg could be either situation. So to avoid that my current implementation finds the longest wiki name that is listed on the server.

This could lead to problems if you have a wiki on Foo and have a subfolder Bar with files in it and everything works but then you make a wiki on Foo/Bar and suddenly those files aren't accessible.

This has nothing really to do with where on the computer these files are located, it is a matter of how you address the files and control access to them. If you don't care about access control and want everything together just set the file path root to something like / and then you have access to the full computer. This is only for situations where you want to have files that are for specific wikis.

[Mark S.]

Hi Jed,

Why is the proposed structure files/Wiki and not Wiki/files (for files limited to a particular Wiki) ?

Thanks!

-- Mark

[Jed Carty]

Mark,

Originally it was to avoid a problem that it turned out I had to solve anyway and now there isn't really a reason to not use that. After having trouble with it before I didn't consider it again but that is a good choice.

I will try to set it up so it is Wiki/files and then there shouldn't be trouble as long as I disallow 'files' as a path component.

Thank you, I think that this is a problem I was staring at too much and missed the obvious solution when it was available.