On 6/24/05, Andreas Hartmann <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > I am wondering how best to implement document security. My current > > project handles it in XSL, but XSL should be for formatting, not > > functionality. > Hmmm, I wouldn't think that way round. The purpose shouldn't be > defined by the technology, but rather the other way round. If you > find XSLT suitable for your needs (although I agree that it seems > strange to use them for security :) ), why shouldn't you use it?
Lenya is a platform; the more it provides, the less a developer needs to code. Because security was left out, I had to design and code more. That reduced my productivity. It will also reduce the productivity of all maintenance programmers, since they have more code to maintain. XSL is the last level before content. It contains the formatting. The formatting should be changable without chancing hurting security. You can see my implementation at: http://solprovider.com/lenya/security With the modified menu.xsl, it is easy to hide menu items with XSL. It would require complicated XSL to block access to documents in multiple sections. And there is an "awareness" security flaw: an unauthorized page returns different than a nonexistent page. The message in both cases should be: "The page requested is missing, or you are not allowed to access it. You may need to login." > > It could be handled in a Sitemap with something like > > auth-protect, but that is where application functionality is defined; > > a Usecase sitemap should not bypass the security because the author > > forgot to copy something. I think it needs to be built into the File > > Generator. That might be a Virtual Component (if they exist), but > > hardcoding into the Java would be best. > Maybe it could even be added in the repository layer, or at least > in the RepositorySource (lenya:// protocol). Then it wouldn't be > restricted to generation, but it would also apply to all other > operations on a document. Great! 1. The protocol gets request for a file. 2. Checks if document exists. 3. Checks if security exists for file. 4. Checks if security passes for file. 5. Checks if language exists. - language-version-does-not-exist flag: (document-level, but falls up path to publication flag) E = Standard error D = Fallback to default language (Standard error if it does not exist.) C = Show language choice page (nolang.xml explained below.) 6. If any check fails, return publication error message. If publication does not have error message, use global error message. If this is implemented, we can remove these from the Pipelines: - language-exists Action - document-does-not-exist Exception because it would be impossible to create them. Sitemaps become slightly simpler; productivity increases (less code!) Where is the security config? sitetree.xml? Where are the error messages? An errors directory under config or content? - error.xml (Standard Error for NotFound, NoLanguageVersion, and NotAuthorized) - anonerr.xml (Standard Error suggesting login, fallback to error.xml) - nolang.xml ("<i18n>The requested document is available for these languages</i18n>: de, us, xx.") solprovider --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
