#pyramid

gavinc: hey big papa

goodwill: hey hug pirate, I owe you money

gavinc: oh right

goodwill: I would just grab that code from pyramid_celery and load up the whole app instead of doing bootstrap

oops

I get goodwill and gavinc confused sometimes

So do we

sontek: I hug more ... thats how you can tell us apart

otherwise we are identical

gavinc: just curious -- have you looked at crossbar.io 's WAMP server?

does anyone have experience w/ object-level acls in pyramid?

that would be the standard case, so, yes, probably lots of people.

sorry let me rephrase my question

say I have a collection of "stories", I need the creator of any given "story" to be able to give access to its "story" to all users that have "user.group"="xyz"

user can decide whether to give read or write access

and what's the question?

what is the best solution to achieve that with pyramid?

story.__acl__ = [(Allow, 'group.xyz', ('read', 'write')), etc...]

the only part that pyramid cares about is after the access has been granted, how does that object turn the grant into an __acl__

and so you need to define an __acl__ and put some code in there that returns the right thing... the right thing would be dependent on how you are persisting the access info

any way to store that in the DB?

yeah.

you could have an __acl__ column

of course, but that's up to you how you do that :-)

or you could make __acl__ a property that generates an acl from other data in the database...

I see

look at raydeo auth demo ;)

you need to define Store.__acl__ so it returns that list

maybe we are talking about

class Story(object):

as long as the context has an __acl__ for pyramid to examine, you're golden.

@property

def __acl__(self):

# do some queries and return a list of access for this story

you can use a route factory for this

this assumes, of course, that the Story object is already the context for the request.

then, i also need to query the db by __acl__, e.g. give me all stories that current user can read

for doing lists like that the __acl__ is less ideal

you'll want to store the data in a way that you can query easily for both cases... __acl__ may not be that form

maybe convert to JSON?

json is not so queryable

it is in my case (ElasticSearch)

well that's up to you of course

I think in terms of database tables since we said DB :-)

I just simplified for example sake :)

well the only part pyramid cares about is the acl on the context... the rest is up to you

but even if a DB, hstore in postgres is queryable and mongodb doesnt care

thanks @raydeo

mongodb isn't a db, but yes there are ways to make it queryable ;-)

i think you have enough knowledge to make something that will work. go forth and rock some code.

also thank you @chrisrossi and @blaflamme

jstoiko_: you're welcome... how's the poster in the office :P

not yet up but looking great on the table :)

o_O... OMG!

jpenny: at some point calling /status every 3 seconds for ever user with an open tab will be a bad idea, but it isn't yet ;)

ok. I don't really have anything in production with it yet, but, it looks very nice for this kind of use-case.

As long as you ignore their web server ;-)

dear Pyramid experts, can anyone tell me if there's a way to retrieve full information about cookies from the Request object (not the Response)? The request.cookies dictionary seems to only give me access to name: value mapping.

j_bennet: dunno what you know about cookies but that's all the browser sends back

you can look at the raw request via your browser debugger or any other tool... that's all you get

raydeo: this comes from HTTP_COOKIE env variable, right?

well it's from the Cookie header which is called HTTP_COOKIE in the wsgi environ

raydeo: i see... so there's no way to recreate the cookies fully?

what info are you hoping for?

expiration date and stuff? that's info for the browser to use to determine when to send back the name-value mapping

it's not sent back to you ever

the timing info for cookies is NOT sent with the cookies to the server, it's brower local

for VERY VERY good reasons :D

i see... yes, path, domain, expiration date, that's the info I'm looking for

thank you

Ugh, I seem to have found a global.

Connection objects are really very annoying ;)

If only all of them were as nice as SQLAlcs