On Apr 9, 6:07 am, carlo <[email protected]> wrote:
> I think I have found the problem:
:-) Yes, you did!
>
> in the models folder I had 3 files: db.py, lastdb.py, menu.py.
> Lastdb.py was an old copy of db.py but, as far as I remeber, there was
> no "auth.settings.actions_disabled.append('register')" in it.
>
> After I deleted lastdb.py it worked as expected: I think that
> lastdb.py was executed after db.py, Auth tables (re)created and set
> auth.settings.actions_disabled=[]. Does it make sense to you?
Maybe if you thought of this all as being in one "file" - or better,
one execution stream, this would start making sense:
For a running web2py, a request gets routed to an application /
controller / function by gluon/main.py --
To set up the environment for that call, gluon (web2py core) runs all
the model files, and then calls the function in your controller.
Here's what that means:
In your application's models folder, all the *.py files are read (in
alphabetical order - this is your "file" processing stream).
Once the data associations, and database connections are in place,
then your controller is ready for a call.
In your case, the model-stream that was setup was: db.py, then
lastbd.py, then menu.py.
If you say something like "auth=Auth()" you are creating a new
instance of an object, and using Auth (the class) to initialize that
instance.
If you have another assignment to the variable "auth", the first
"reference" to the created object is released, and auth is pointed to
the new, initialized object.
In your case, lastdb.py created the second Auth() instance, and re-
assigned auth to point to this new object. The new object's default
setting was to NOT have registration disabled.
If this is making sense, then you will know that when you do
development experiments like this, you will want to rename your "last"
file at the tail-end, e.g.
rename db.py to db.py.last is a better choice - since it is then no
longer a python file, and will not get read.
You'll find for references to 404 in www.web2py.com/book...
Have lots of fun!
- Yarko
>
> Another small question:
>
> what do you suggest as the best way to show the user a kind page
> instead of "404 NOT FOUND" after he tried registration?
> thank you
> carlo
>
> On 9 Apr, 12:48, carlo <[email protected]> wrote:
>
> > thank you all.
>
> > Thadeus:
> > in my model below the place Auth tables are created;
>
> > Massimo:
> > no I do not have my register action, everything is web2py Auth out of
> > the box.
>
> > Yarko:
> > Definitely not routes fault: I commented my routes but I still can
> > access the registration page.
> > I am down at debugging, later I will post more results.
>
> > carlo
>
> > On 9 Apr, 00:45, Yarko Tymciurak <[email protected]> wrote:
>
> > > On Apr 8, 4:43 pm, carlo <[email protected]> wrote:
>
> > > > thank you Yarko for replying. Well it is really a strange behaviour, I
> > > > am trying to isolate the problem.
>
> > > Try with just a fresh app first - just a clone of "welcome" with auth
> > > enabled, auth.requires_login() set for default/index, and not more.
>
> > > Then try appending the actions_disabled - no routes, nothing: just
> > > get to this point first.
> > > THEN --- if you think you are having problems with routes, add routes
> > > to _just that minimal test_.
>
> > > You can use your favorite debugger, and set it to ~ line 270 in gluon/
> > > tools.py, to this:
>
> > > elif args[0] in self.settings.actions_disabled:
> > > raise HTTP(404)
>
> > > and confirm that auth.__call__ is happening, that your setting is
> > > there.
>
> > > If you want to add your routes changes, and debug those, I'd start
> > > with using the "canned" generic.html view, where you can see all the
> > > request vars - this will help you also.
>
> > > Anyway, the point is: separate it to "one problem" at a time.
> > > Otherwise it _will_ seem hard to "make sense" of things, separate out
> > > what is going on.
>
> > > Hope this is helpful.
> > > - Yarko
>
> > > > For now I have the feeling that my problem ha something to do with
> > > > routes.py, this is my routing rule:
>
> > > > routes_in = (('/$f', '/init/default/$f'),)
>
> > > > routes_out = (('/init/default/$f', '/$f'),)
>
> > > > In fact the login page, where you are redirected after you call an
> > > > auth-decorated function, breaks the above rule:
>
> > > >http://www.mysite.com/init/default/user/login?_next=/add
>
> > > > Do you think this make any sense? Could this in any way affect the
> > > > 'register' page so that it is not disabled?
>
> > > > carlo
>
> > > > On 8 Apr, 19:27, Yarko Tymciurak <[email protected]> wrote:
>
> > > > > I've just tried this in both trunk, and 1.76.5, and in each I get a
> > > > > "404 NOT FOUND" when I hit "register"...
>
> > > > > Perhaps say more about what you are doing that you think this does not
> > > > > work...
>
> > > > > On Apr 8, 10:05 am, carlo <[email protected]> wrote:
>
> > > > > > Following the manual I put this statement in my model file but it
> > > > > > seems I can still access the register page and register a new user:
> > > > > > did I miss something?
>
> > > > > > carlo
>
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > > Groups "web2py-users" group.
> > > > To post to this group, send email to [email protected].
> > > > To unsubscribe from this group, send email to
> > > > [email protected].
> > > > For more options, visit this group
> > > > athttp://groups.google.com/group/web2py?hl=en.
>
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "web2py-users" group.
> > > To post to this group, send email to [email protected].
> > > To unsubscribe from this group, send email to
> > > [email protected].
> > > For more options, visit this group
> > > athttp://groups.google.com/group/web2py?hl=en.
--
To unsubscribe, reply using "remove me" as the subject.
