> There are a couple of things about security. If a principal is unable > to edit any wiki topic in the federation, then that principal will not > be able to upload any files. If a principal has permission to edit a > topic, then that principal can upload a file and include that file as > an attachment on the topic being editted.
Which is not entirely unreasonable given the nature of the patch, IMO. It's better than nothing, and although it provides zero control over reads, if that's not a concern for people (perhaps it's an intranet site, or the information is public) they might not care. But I think it's also one of the primary reasons we should ship this feature in "default off" configuration. > At this point the upload capability is at the federation level, but it > would be relatively easy to revise the capability so that it is > contained within the namespace. Security could be improved by adding a > 4th verb "Upload" to the existing security verbs of "Read", 'Edit" and > "Manage Namespace". The semantics for this verb would be identical to > the other verbs. So, I'd oppose this fairly strongly. I don't really want to screw with the core to support a bolted-on feature of the web app, particularly since we're still not controlling read access. But even if we were, then there's good reason not to change the security model. To start with, it was *really hard* to get the current model to where it is, and I happen to think it's pretty good (ah, humility ;). For example, allowing edit implies allowing read. Would upload imply edit? Vice versa? You see the difficulty, and that's just part of it. For another thing, the number of tests that would have to be added to verify that no (obvious) holes were being opened is fairly large. I.e. this is not a trivial modification of the core. At that point it starts to make more sense just to go whole hog and add non-wikitext content in the core where it belongs anyway. Particularly because I think it can be done without modifying the security model, thus making it a separate provider under the new architecture. This sort of separation makes the code easier to modify, maintain, and test. Massive tangling of features was the main reason I had to rip the core apart to add security in the first place: it was going to be nearly impossible the way it was written with caching and built-in topic detection repeated everywhere throughout the app. [1] So I'd really rather see attachments done in the core completely or left as an optional bolt-on feature of the web app. For my part, I agree with Derek that the most sensible route is to ship web attachments as an opt-in, it's-going-away-use-at-your-own-risk feature of 2.0 and get the full-on version shipped in something that happens after 2.0 RTW. [1] There's still a fair amount of this sort of refactoring left to do, in fact. For example, parsing is still spread all over the place, and I think there should be a Topic object rather than the scattershot of methods spread all over Federation, NamespaceManager, and ContentProvider. But it's bad enough it took me *this* long to refactor. Maybe in FlexWiki 4.0. :) ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Flexwiki-users mailing list Flexwiki-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flexwiki-users
