So now here I am thinking I’m getting incrementally closer to having a
UserEngine setup that works, copying a controller into my app, putting
sitewide authorization in application.rb and assigning privileges on my
“public” controller to Guests and most things seemingly work.
Then I tried logging out to test one of my privileged non-admin users on
a site maintenance page. I accessed /user/logout and the app told me I’m
logged out. But when I then went to a protected URI, instead of being
redirected to /user/login as I am on my development box (which works
absolutely as it should no matter what I throw at it), I am allowed
access. Which either means permissions aren’t working in a dangerous way
(if the code is broken, failure should result in denial, not access), or
I’m not really being logged out despit being presented with HTML that
says I have been.
What versions of Engines, LoginEngine and UserEngine are considered most
likely to work on a Ruby 1.8.2/Rails 1.0.0 box and SwitchTower
deployment?
Thanks!
Steve K. [email protected] writes:
Then I tried logging out to test one of my privileged non-admin users on
a site maintenance page. I accessed /user/logout and the app told me I’m
logged out. But when I then went to a protected URI, instead of being
redirected to /user/login as I am on my development box (which works
absolutely as it should no matter what I throw at it), I am allowed
access. Which either means permissions aren’t working in a dangerous way
(if the code is broken, failure should result in denial, not access), or
I’m not really being logged out despit being presented with HTML that
says I have been.
Check the session variable, it should be set to nil, if you log out. If
you
are using database to store session then check that, the corresponding
session
entry is removed.
Check the permissions_roles table, and verify that the permissions are
correctly set, or not present for the guest user.
See if you have before_filter: authorize_action enabled, and that it is
indeed being called.
Also, set up tests which will automatically check whether entry is
enabled or
disabled for different users.
As a developer don’t just go by HTML because it might be rendered by
some
other bug, and may be misleading.
Hope this helps.
Surendra S.
http://ssinghi.kreeti.com, http://www.kreeti.com
Read my blog at: http://cuttingtheredtape.blogspot.com/
,----
| Great wits are sure to madness near allied,
| And thin partitions do their bounds divide.
|
| (John Dryden, Absalom and Achitophel, 1681)
`----
Thanks. Good advice. Looks like it turned out to be a bug in the Engines
plugin’s handling of path names with hyphens for which a one-line fix
was reported a month ago. But since the fix was reported in the old (and
still operational) Trac bugbase and not the new Collaboa bugbase it
hasn’t found its way into the trunk yet. See my more recent thread if
you’re curious.
In short, the crucial difference between my dev and prod environments
was that the prod environment had my app in a directory path under
/usr/local/www/rails-apps/… The hyphen in “rails-apps” was causing the
problems, and with the offending regex in Engines fixed, none of the
other workarounds I had in place were necessary anymore.
Surendra S. wrote:
Steve K. [email protected] writes:
Then I tried logging out to test one of my privileged non-admin users on
a site maintenance page. I accessed /user/logout and the app told me I’m
logged out. But when I then went to a protected URI, instead of being
redirected to /user/login as I am on my development box (which works
absolutely as it should no matter what I throw at it), I am allowed
access. Which either means permissions aren’t working in a dangerous way
(if the code is broken, failure should result in denial, not access), or
I’m not really being logged out despit being presented with HTML that
says I have been.
Check the session variable, it should be set to nil, if you log out. If
you
are using database to store session then check that, the corresponding
session
entry is removed.
Check the permissions_roles table, and verify that the permissions are
correctly set, or not present for the guest user.
See if you have before_filter: authorize_action enabled, and that it is
indeed being called.
Also, set up tests which will automatically check whether entry is
enabled or
disabled for different users.
As a developer don’t just go by HTML because it might be rendered by
some
other bug, and may be misleading.
Hope this helps.
Surendra S.
http://ssinghi.kreeti.com, http://www.kreeti.com
Read my blog at: http://cuttingtheredtape.blogspot.com/
,----
| Great wits are sure to madness near allied,
| And thin partitions do their bounds divide.
|
| (John Dryden, Absalom and Achitophel, 1681)
`----