It's pretty straightforward - there are 2 registration links in the menu and each of them links to default/register/[group_type]. Then, in the view, request.args(0) value is being checked to generate respective form. Guess, I'll go for the request.args(0) limitation, as you wrote.
By the way, can I stop (revert?) the registration process when user tries to register with non-specified URL argument? Like this: 1. User submits the form 2. onaccept callback checks if the URL argument is equal to one of 2 specified 3. If not, registration takes no place (new user is not created) and the application redirects to a different (error) page W dniu piątek, 7 czerwca 2013 15:23:00 UTC+2 użytkownik Anthony napisał: > > How do users get to their respective registration URLs to begin with? If > they are sent a link via email, you could use a digital > signature<http://web2py.com/books/default/chapter/29/04#Digitally-signed-urls>. > > If they are allowed to choose the group themselves by making a selection, > then your current method is fine, but you should still check that > request.args(0) is limited to only the two allowed groups (so if you have > an admin group or some other roles with greater restrictions users won't be > able to assign themselves to those roles). > > Anthony > > On Friday, June 7, 2013 6:39:56 AM UTC-4, lesssugar wrote: >> >> That's my concern also. I simply would like to make a transparent >> registration for 2 groups separately. In order to do so I have two >> different forms generating depending on URL argument: >> default/register/[group1] or [group2]. Checking request.args(0) on >> "onaccept" seemed obvious but it needs improvements. >> >> Is it a good idea to check also a specific form id attribute when >> performing onaccept? How do I check the form id attribute value? Or maybe >> there's a better way do make sure noone messes with the URL arguments? >> >> On Friday, June 7, 2013 3:18:29 AM UTC+2, Anthony wrote: >>> >>> Yes, you should not call .process() after calling auth.register() >>> because the second time through .process() it will fail (the _formkey token >>> is only good for one process -- so it fails on the second). Using an >>> onaccept callback is the way to go. However, it appears you are allowing >>> your users to assign themselves to any arbitrary group simply by >>> manipulating an arg in the URL -- that doesn't seem like a good idea. >>> >>> Anthony >>> >>> On Thursday, June 6, 2013 7:56:56 PM UTC-4, lesssugar wrote: >>>> >>>> OK, I figured out something like this and it works (let me know if it's >>>> not correct in any way): >>>> >>>> In db.py model: >>>> >>>> auth.settings.create_user_groups = False >>>> >>>> and then >>>> >>>> def add_group(form): >>>> group_id = auth.id_group(role=request.args(0)) >>>> auth.add_membership(group_id, form.vars.id) >>>> >>>> auth.settings.register_onaccept.append(add_group) >>>> >>>> >>>> >>>> >>>> On Friday, June 7, 2013 1:35:41 AM UTC+2, lesssugar wrote: >>>>> >>>>> Sorry, there is one more "but". After renaming the form all goes well, >>>>> except that this piece of code >>>>> >>>>> if register_form.accepts(request.vars, formname='register'): >>>>> auth.add_membership(group_id=1, >>>>> user_id=register_form.vars.id<http://register_form_s.vars.id> >>>>> ) >>>>> >>>>> no longer adds the right membership to user. It gives them the default >>>>> group: user_[id], while earlier adding to "group 1" worked properly. >>>>> >>>>> On Friday, June 7, 2013 1:11:23 AM UTC+2, Anthony wrote: >>>>>> >>>>>> I think the form processing within the auth.register() function is >>>>>> probably failing because you have renamed the form to 's_registration', >>>>>> and >>>>>> it is expecting a form named 'register' (it uses the formname to check >>>>>> the >>>>>> _formkey value in the session). If the form doesn't get accepted, it >>>>>> doesn't get to the redirect logic. >>>>>> >>>>>> Anthony >>>>>> >>>>>> On Thursday, June 6, 2013 6:59:51 PM UTC-4, lesssugar wrote: >>>>>>> >>>>>>> Right, thanks. But what about the "next" attribute? What might be >>>>>>> the reason of the argument not working? >>>>>>> >>>>>>> On Friday, June 7, 2013 12:53:35 AM UTC+2, Anthony wrote: >>>>>>>> >>>>>>>> auth.register() automatically processes the form, so you should not >>>>>>>> subsequently call request_form.process(). >>>>>>>> >>>>>>>> Anthony >>>>>>>> >>>>>>>> On Thursday, June 6, 2013 6:21:52 PM UTC-4, lesssugar wrote: >>>>>>>>> >>>>>>>>> After user registers, I would like to redirect them to a different >>>>>>>>> URL, let's say default/index. >>>>>>>>> >>>>>>>>> Auto-login in db.py is set to False. >>>>>>>>> >>>>>>>>> In my default.py controller I have this: >>>>>>>>> >>>>>>>>> register_form = auth.register(next=URL('default', 'index')) >>>>>>>>> register_form.update(_class='formstyle', _name='s_registration') >>>>>>>>> if register_form.process().accepts(request.vars, >>>>>>>>> formname='s_registration'): >>>>>>>>> auth.add_membership(group_id=1, >>>>>>>>> user_id=register_form.vars.id<http://register_form_s.vars.id> >>>>>>>>> ) >>>>>>>>> >>>>>>>>> return dict(register_form=register_form) >>>>>>>>> >>>>>>>>> So after user registers, no redirection takes place. However, the >>>>>>>>> registration itself is correct (checked auth_user and auth_membership >>>>>>>>> in >>>>>>>>> the DB). >>>>>>>>> >>>>>>>>> Any suggestions why "next" argument does't get the job done? >>>>>>>>> >>>>>>>>> UPDATE: >>>>>>>>> If I add "redirect(URL('default', 'index'))" in the IF condition >>>>>>>>> (code above) - all goes fine. What's with the "next" argument then? >>>>>>>>> >>>>>>>>> -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
