Hi JP sorry for the lare reply see comments inline
Jean-Philippe Courson wrote: > > We first have to establish a road map : I think that we could first > integrate > user's quota into branch 1.0 and to deal with versioning and properties move > to the structure later. > > Others issues are : plug quota correctly, transactions, forbid users > to remove their node locks and deal without contentLengths. > > 1) Plug quota correctly : > Ok to make ContentInterceptor abstract and for UserQuotaContentInterceptor, > but what are you meaning by pluggable Interceptors ? > Which is the way they should be plugged ? Today the interceptors can be configured in the domain.xml file (NamespaceConfig.java:834) UserQuotaContentInterceptor should follow the same principle. > 2) Transactions : > I first need to have a look at transactional code. > Basicaly, how rollbacks are performed ? > Transactions scheme in the doc indicates that helpers can act with stores > without using the transaction manager. Is it rigth ? If yes in which cases ? For read only operations you don't have to start a transaction. You can do write operations as well, you get only a warning not an error but you better don't. The behaviour is undefined, the store can revert your changes at any time, store all you changes or silently ignore everything. > 3) forbid users to remove their node locks : > This can be done now with permissions. > But how would internal locks be placed ? Using which credentials and > sort of token ? (from the second mail) > Sorry for the mistake : forbid users to remove their node locks can't > be done with permissions. Some internal locks placed using root > credential or something like that need to be done. > > But performing all actions in code using a token with user's credential > is a very good concept for security. > > What can we do ? The lock on the user node is not really an absolute requirement. In the postStoreContent, you can check the quota again and if the user has gone over his limit reject and rollback. Then there is only some waste of CPU and bandwith. > 4) Null contentLength headers : > Are there webdav clients that don't send them ? > Allowing such requests processing is a big DOS attack risk. Make it a configurable option, there will always be clients that misbehave allow content with unknown size = true/false > > JP Cheers Dirk -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
