Hi Dirk, >>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.
Apparently, Remy wishes to rewrite himself the code that plugs Interceptors to make it more generic. I'm waiting him to commit the code to plug myself smoothly. >>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. If I place a lock on the user node and a rollback occurs, is it possible to know what will happen to the lock ? >>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. Waiting to have system locks, I prefer the solution with user lock if it does not cause problems with transactions rollbacks : it would then be more difficult to waste 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 +1 Which sort of exception should we throw if this parameter is set to false and a request have a null contentLength header ? JP -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
