Re: Quota soon supported !

[Dirk Verbeeck <di...@pandora.be>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Quota soon supported !

[Remy Maucherat <re...@apache.org>]

> 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.

I plan to commit the interceptor initial code ASAP, son that we can work on
further improvements. The name you suggest looks good :)

Remy


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>