temporarily I've renamed def agent() back to def user()

the only problem I'm left with is how to get my one-off registration code to
be called.

for users registering by a registration form all is well.
For them I've set: auth.settings.register_onaccept = lambda form:
registerCandidate(form)

But for users via LinkedIn... no registeration step is called;
and auth.settings.login_onaccept = lambda form: registerAgent(form) is
ignored too.

One solution is to change:
auth.settings.login_next = URL(r=request,f='account')
to: auth.settings.login_next = URL(r=request,f='oneoffregistration') which
can do the one of stuff and then redirect to 'account'

But I feel there must be a way that leverages the framework more elegantly.
Is there? :)


On 16 October 2010 03:51, mdipierro <mdipie...@cs.depaul.edu> wrote:

> I did not realize that...  can change it but for now it is indeed a
> problem. One solution would be to extend Auth and override url()
>
> On Oct 15, 9:07 pm, Carl <carl.ro...@gmail.com> wrote:
> > One small problem I'm coming across...
> >
> > I'm using OAuth to login via LinkedIn for a subset of my users.
> >
> > In gluon/tools.py line 1471 the statement hard-codes 'user' (web2py
> 1.87.3)
> > next = self.url('user',args='login',vars=dict(_next=next))
> >
> > Is there something I should have done to avoid this route through the
> code?
> > I'm currently using it to pass a "return url" to LinkedIn and I'd like a
> > different url besides /user/
> >
> > On 16 October 2010 01:01, Carl Roach <carl.ro...@gmail.com> wrote:
> >
> > > Thanks M
> > > I'll base my agent user type on your approach
> > > Thanks again for taking the time
> >
> > > On 16 Oct 2010, at 00:48, mdipierro <mdipie...@cs.depaul.edu> wrote:
> >
> > > > This is what I normally do:
> >
> > > > 1) I use LinkedIN with RPX (but should be same with OAuth)
> > > > 2) my auth_user table is populated automatically when users login via
> > > > RPX
> > > > 3) my auth_user table as a field "registered' invisible and defaults
> > > > to false
> > > > 4) my model has this code
> >
> > > > if auth.user and request.function!='user' and not
> > > > auth.user.registered:
> > > >    redirect(URL('default','user/profile'))
> >
> > > > 5) this forces users to complete a registration process.
> > > > 6) my auth_user table also a boolean manager field that defaults to
> > > > false.
> > > > 7) I use appadmin to promote users to managers
> >
> > > > On Oct 15, 6:40 pm, Carl Roach <carl.ro...@gmail.com> wrote:
> > > >> I've got authentication working with LinkedIn. But no registration
> step
> > > happens... I would like to add a set of permissions the first time a
> new
> > > user logins in via LinkedIn.
> >
> > > >> For a second type of user I offer a registration page to get
> > > email/password and then add a different set of permissions.
> >
> > > >> So the piece I'm missing is: how do I fire off a registration step
> for
> > > my "LinkedIn" users?
> >
> > > >> On 16 Oct 2010, at 00:19, Radomirs Cirskis <r...@nowitworks.eu>
> wrote:
> >
> > > >>> Hi Carl!
> >
> > > >>> you can implement two registration similar to the technique Massimo
> > > >>> advised the authentication.
> > > >>> You could look into CAS. Not 100% sure, but it could be solution
> for
> > > >>> your case. I could be mistaken. Can you elaborate further on what
> you
> > > >>> are trying to achieve?
> > > >>> rad
> >
> > > >>> On Oct 16, 10:00 am, Carl <carl.ro...@gmail.com> wrote:
> > > >>>> thanks M.
> >
> > > >>>> adding to def candidate()
> > > >>>>     auth.auth_user = 'candidate'
> > > >>>> has that side sorted.
> >
> > > >>>> for my function agent() the process is a little more complicated.
> > > >>>> While Candidates have to "formally" register first and then login
> > > agents can
> > > >>>> be "automatically" registered (I need to add some permissions and
> do
> > > other
> > > >>>> one-off stuff) when they come back from LinkedIn.
> >
> > > >>>> The problem is that registration doesn't take place at all and I
> can't
> > > >>>> figure out how to get this one-off registration phase called. can
> you
> > > point
> > > >>>> me in the right direction?
> >
> > > >>>> On 15 October 2010 19:22, Carl <carl.ro...@gmail.com> wrote:
> >
> > > >>>>> I'm glad I don't need two user tables. I ideally would want to
> stick
> > > to a
> > > >>>>> single table.
> >
> > > >>>>> On 15 October 2010 19:14, mdipierro <mdipie...@cs.depaul.edu>
> wrote:
> >
> > > >>>>>> Not necessarily and I would not do it that way but you can.
> >
> > > >>>>>> On Oct 15, 1:12 pm, Carl <carl.ro...@gmail.com> wrote:
> > > >>>>>>> thanks M.
> >
> > > >>>>>>> Do I understand that your solution is to have two separate user
> > > tables
> > > >>>>>> in
> > > >>>>>>> db.py?
> >
> > > >>>>>>> On 15 October 2010 18:42, mdipierro <mdipie...@cs.depaul.edu>
> > > wrote:
> >
> > > >>>>>>>> look into default. You can replace
> >
> > > >>>>>>>> def user(): return dict(form=auth())
> >
> > > >>>>>>>> with
> >
> > > >>>>>>>> def agent(): return dict(form=auth())
> > > >>>>>>>> def candidate(): return dict(form=auth())
> >
> > > >>>>>>>> and in the two functions you can set different default for
> > > auth_user
> > > >>>>>>>> fields.
> >
> > > >>>>>>>> On Oct 15, 8:45 am, Carl <carl.ro...@gmail.com> wrote:
> > > >>>>>>>>> Is there a way to use [app]/default/agent instead of
> > > >>>>>> app/default/user?
> >
> > > >>>>>>>>> I want to have two implementations of authentication (/agent
> and
> > > /
> > > >>>>>>>>> candidate)
> >
> >
>

Reply via email to