#pyramid

evagelos: after calling testing.setUp() the registry will be a dummy one with your settings etc

get_current_request will only return something you care about if you pass setUp(request=request) otherwise it's probably none

however if you later instantiate a DummyRequest it will use the threadlocal registry from setUp for it's operations

is it just me, or is there something really wrong with debugtoolbar now?

throws exceptions if I didn't have a session implementation...

let's pretend it's just you

are you on the latest toolbar?

raydeo: u said "after calling testing.setUp()..." you assume that i pass the settings right? cause u didnt specify it in ur sentence

(just to be clear)

raydeo: ah I just read wrong...

it is csrf protection :F

I thought it comes from debugtoolbar because it was mentioned in the trace at the bottom, but it just hooks some request vars it seems

it is because by default I am turning csrf on, but this is a jsonrpc endpoint that does its own auth anw, then it is not needed.

require_csrf=False !!

raydeo: so easy ;)

but no, https://github.com/Pylons/pyramid_rpc/blob/mast... can't give require_csrf here ;)

ztane: I dunno if you saw my comments on https://github.com/Pylons/plaster_pastedeploy/p... but without a fix + tests I won't get this fixed probably for a while... life has been quite busy lately

yeah I suppose you can't

well, I don't know either how to fix that (I don't have tests either) I just noticed it there when reading the source.

I guess the add_jsonrpc_endpoint could eat view_predicates

it sends them to add_route

I mean have an arg

a view_options is a possibility

but I'm not sure I like that... probably just a specific arg for require_csrf

well, that would work too, but are there any others?

well you can see there are two default views which we want to be careful about

both of those views would probably just set require_csrf=False always

one is an exc view so it doesn't matter

the other is the batched view which executes subrequests so it falls back to whatever each of those methods is set to

so you're just talking about some default options for each rpc method

and obviously for jsonrpc csrf should be the same for every method

but I'm not sure about other view options

I'd lean toward just a setting for require_csrf and not a generic pass through without some other examples

the rpc api is kind of intentionally constrained

yeah. writing some test code, I guess the csrf flag if set should also be stored on the endpoint, doesn't make sense for it to be any different for the other requests...

yeah I mean a method_options or something isn't crazy either I suppose

with view derivers in the mix now it isn't crazy to want to apply some derivers to all of your methods

hmmm... I was thinking that it would be quite nice to have a mapper that used type hints...

garh, need to have 6 different cases for the csrf flag to test that it is actually working, 2 x 3 :D

Interesting post, moo-_-

ztane the build is failing. i have no idea how to handle the last two failures. https://travis-ci.org/Pylons/pyramid_rpc/builds...

stevepiercy: ah :) coverage failure, interesting.

argh

ztane the pyramid 1.4 and 1.5 failures?

stevepiercy: this requires pyramid 1.7 with this addition...

yup

it could be made to work with 1.4, 1.5, and then only the require_csrf-specific tests need be skipped.

and a tox modification

I'm ok with you bumping the minimum dep to 1.7

as for the first failure, the views could be replaced with a lambda function ;)

raydeo also remove py3.3 and add py3.6?

and add py nightly, or whatever it's called?

yes well the feature also needs to be added to xmlrpc

yea

(though I wonder who wants to build anything new with xmlrpc :D)

warehouse uses it

yeah poor dstufft

lol, one line missed

strange, now I get json result '', when returning from an actual view...

*sorry, json text is ""

I've got a custom json renderer...

(Pdb) response.body

b'""'

lol

ah because... notification.

however shouldn't it return no body

yea

Hi, when implementing Facebook login on a mobile client, what kind of auth library would you recommend for the Pyramid backend? As I see from the recently updated ones there is Authomatic and the new python-social-auth. Social's Pyramid project is very new though and only has 2 stars, I wonder if anyone has used it.

python-social-auth itself has been around for a long time probably just not a lot of usage with pyramid

anyway probably either authomatic or psa or the right answer if you don't want to implement it yourself

So both of them are considered reliable. Do both of them only do strictly the initial authentication, or they also go into authorization. Or I should just do it myself with session / JWT?

I don't use them... I've just seen your type of question more than once in this channel

when I did facebook login I implemented it myself

hyperknot: I use authomatic, worked well for me

Thanks. And do you know of any resources which describes how to implent it yourself, even if I'll finally settle on authomatic or psa? What I'm trying to understand is what are the needed steps for the backend when authenticating a native mobile app via facebook.

hyperknot: there are examples for authomatic/webob on their site

the flow for native mobile might be different though

thanks

hyperknot: for "diy" it's just the facebook docs

raydeo: I didn't really find any information in there, but probably I wasn't looking in the right place. Right now https://developers.google.com/identity/protocol... looks to be a much higher quality document.

perhaps... they have SDKs for most platforms or there's just https://developers.facebook.com/docs/facebook-l...

you shouldn't dive into that stuff unless you understand oauth2 pretty well already though

Right now what I'm tring to understand is what kind of model I need in my database for social auth-ed users, as well as if I need to use an provider specific library, or just an oath lib, or maybe a simple request would work?

well you need to store their userid and usually also their access token information (allowed scopes, expiration time, token, refresh token)

depends if you care about anything more than their userid really

you'll almost always need the token in order to query their email address and any other profile properties you care about when they connect the first time

but after that you might throw it away depending on what you're doing

raydeo: cool, that's clear! And for this one time querying of things, do I need an auth library like authomatic or just a call in a generic oath lib?

oauth2 is pretty trivial to do on your own but in the past I've used requests-oauthlib as a helper around requests as well

it's basically just a request to the endpoint with the authorization header set to your access token... so there's not much to it unless you are trying to do stuff over a much longer period of time