Auth support for RIFT (ACL) and so on.

[asilenkov]

1. We gonna implement some auth for our content.
2. Bucket ACL - READ: anon public/not public auth with key access/no access
3. Object ACL - READ: anon public/not public auth with key access/no access
4. May be temporary key with expire date. Like in S3.
5. Some mix of rules - bucket is private but some objects within are not and vice versa.

As far as I could understand now we have only simple auth check for bucket (ughh namespace).
Could we suggest it to fulfill roadmap if any ))

1. Its kinda sad that it's not compatible with S3. We have plenty of tools available like Bucket explorer, Bucket commander, Bucket smth and other stuff. Python Boto, alot of bindings for every language imagined. Fast integration into existing infrastructure hardly possible especially with lack of documentation. Just thoughts though ))

[bioothod]

Buckets are kind of 'acl-with-single-auth-entry', there could be a list of tokens I believe instead of one token per bucket.

Expiring keys are not supported, although they can be implemented manually with appropriate secondary indexes. s3 api is not supported yet, but we think about it

[bioothod]

#‎Elliptics‬ HTTP frontend ‪#‎RIFT‬ got full per-bucket ACL support

http://www.ioremap.net/node/946/
http://reverbrain.com/elliptics-http-frontend-rift-got-full-per-bucket-acl-support/