Jason,
Yes, once we discovered the problem with the inactive users
reproducing it was easy. After digging into the code it became
obvious, tests for inactive users where missing (only a user fixture,
not used in any test) all the tests run now, including the ones we
added for the the inactive users.
You experienced the problem, I would suggest bootstrapping a clean
LBL installation and inactiving a user cleaning the cookies, and
trying to login with the inactivated user.
Best regards,
--
Aníbal Rojas
On Mar 14, 5:52 am, Jason Keenan <[email protected]> wrote:
> Nicely done :) I'm not entirely sure why Steve has chosen to use his
> own authentication rather than just going with
> restful_authentication. Seems like it would take some of the work out
> of things. I must admit I haven't really looked into it but I suppose
> there must be a reason. It's weird how random it was though. Did you
> reproduce the error before you fixed it. It must have taken certain
> conditions to happen cause I was traveling along nicely before it
> happened and I think most other people who have upgraded to the 2.2.2
> version haven't had the issue. I think Steve would be reluctant to
> pull unless you could adequately explain why this wasn't based on
> some bizarre set of circumstances. I think more so considering this
> is in a plugin that I assume he uses in other projects.
>
> Just a thought :)
>
> Jason
>
> On 13/03/2009, at 8:43 AM, Aníbal Rojas wrote:
>
>
>
> > Jason,
>
> > We found the problem, fixed it and there is a pull request for
> > Steven in GitHub now from Jesús de Abreu (geronimo)
>
> > It was kind of nigthmare because what the user was doing was not
> > evident, and after following the track you are suggesting we finally
> > discovered a bug in the authetication mechanism.
>
> > _Inactive_ users were allowed to login, and after their succesful
> > login they where redirected, but check_permissions, so on ad
> > infinitum.
>
> > The patch prevents a inactive user from logging in, and if the user
> > is already logged in and inactivated the filter will log him out.
>
> > Best regards,
>
> > --------------------------
> > Aníbal Rojas �...@anibalrojas
> >http://hasmanydevelopers.com
> >http://rubycorner.com
> >http://en.anibal.rojas.com.ve
> >http://twitter.com/anibal
>
> > On Mar 7, 5:32 pm, Jason Keenan <[email protected]> wrote:
> >> No, That would be a bit too much like good practice ;)
>
> >> If I get some time I might try to reproduce it. I have a feeling it
> >> might have been swapping legacy versions of lovd using the same
> >> database or something and left stale/incompatible session and or
> >> cache data hanging around. Not sure though.
>
> >> Did you? ;)
>
> >> Jason
> >> On 06/03/2009, at 7:20 PM, Aníbal Rojas wrote:
>
> >>> Jason,
>
> >>> In the end, the problem was the data. Not sure exactly what. Do
> >>> you have a backup of your data to check if there is pattern?
>
> >>> Thanks a lot for you help,
>
> >>> --------------------------------
> >>> Aníbal Rojas
> >>>http://anibal.rojas.com.ve
>
> >>> On Thu, Mar 5, 2009 at 11:15 PM, Jason Keenan
> >>> <[email protected]> wrote:
> >>>> Just checked my installation locally and got this
> >>>> Processing HomeController#index (for 127.0.0.1 at 2009-03-05
> >>>> 14:29:09) [GET]
> >>>> Session ID: fde77a3e02fb31d15fb3485d932fd695
> >>>> Parameters: {"action"=>"index", "controller"=>"home"}
> >>>> [4;36;1mUser Load (0.000255) (1 Row) [0m [0;1mSELECT * FROM
> >>>> `users`
> >>>> WHERE (`users`.`id` = 2) LIMIT 1 [0m
> >>>> [4;35;1mProfile Load (0.000312) (1 Row) [0m [0mSELECT * FROM
> >>>> `profiles`
> >>>> WHERE (`profiles`.user_id = 2) LIMIT 1 [0m
> >>>> [4;36;1mProfile Columns (0.002089) (21 Rows) [0m [0;1mSHOW
> >>>> FIELDS FROM
> >>>> `profiles` [0m
> >>>> [4;35;1mSQL (0.000081) [0m [0mBEGIN [0m
> >>>> [4;36;1mProfile Update (0.000346) [0m [0;1mUPDATE `profiles`
> >>>> SET
> >>>> `last_activity_at` = '2009-03-05 03:29:09', `updated_at` =
> >>>> '2009-03-05
> >>>> 03:29:09' WHERE `id` = 2 [0m
> >>>> [4;35;1mSQL (0.000435) [0m [0mCOMMIT [0m
> >>>> IN check_permissions :: @level => [[:all, {:all=>true}]]
> >>>> Filter chain halted as [:check_permissions] rendered_or_redirected.
> >>>> Completed in 85ms (View: 0, DB: 5) | 200 OK [http://localhost/]
> >>>> Weird!!!
> >>>> I did a db:migrate:reset on the database and the problem seems to
> >>>> have gone
> >>>> away. This didn't loop though.
> >>>> Could be some sort of database corruption but not sure what.
> >>>> Jason
> >>>> On 05/03/2009, at 10:17 AM, Jason Keenan wrote:
>
> >>>> Found these references.
> >>>>http://www.ruby-forum.com/topic/150507
> >>>>http://railsforum.com/viewtopic.php?id=27122
> >>>>http://forum.goldberg.240gl.org/viewtopic.php?t=328
> >>>>http://railscasts.com/episodes/20-restricting-access-check comment
> >>>> 14 + 15
> >>>> Not sure if these will help
> >>>> Jason :)
> >>>> On 05/03/2009, at 6:16 PM, Aníbal Rojas wrote:
>
> >>>> Jason,
> >>>> Thanks for your fast response.
>
> >>>> Is it throwing an error?? 1 or 2 seconds between calls seems like a
> >>>> long time so it looks like you may have resubmitted the logins
> >>>> several times rather than it looping by itself. Could that be
> >>>> correct???
>
> >>>> There are no errors in the log, the browser just gives up
> >>>> after a
> >>>> lot of redirects.
>
> >>>> Have you tried different browsers? I did a quick search and the
> >>>> only
> >>>> thing I could find even remotely related led to a session cookie
> >>>> issue with IE7. Not sure if there might be an issue there.
>
> >>>> We use Firefox in a regular fashion, we found the same
> >>>> reference
> >>>> and tried with Explorer without any difference.
> >>>> Actually we went so far as trying Lynx in the server targetting
> >>>> the mongrel port without any luck.
> >>>> --
> >>>> Aníbal Rojas
>
> >>>> Jason
>
> >>>> On 05/03/2009, at 9:05 AM, Aníbal Rojas wrote:
>
> >>>> Hello,
> >>>> This is kind of weird. The applications is really simple,
> >>>> basically a conceptual test built on Lovd by Less, it has been
> >>>> working
> >>>> fine but suddenly started choking on the production server with a
> >>>> infinite redirect loop while trying to login, as the following log
> >>>> sample shows:
> >>>> Processing HomeController#index (for 190.39.201.34 at 2009-03-04
> >>>> 15:48:29) [GET]
> >>>> Session ID: 38521343127c98c9f14cb4c37492fe9c
> >>>> Parameters: {"action"=>"index", "controller"=>"home"}
> >>>> Redirected to /
> >>>> Filter chain halted as [:check_permissions] rendered_or_redirected.
> >>>> Completed in 4ms (DB: 2) | 302 Found [http://STRIPPED/]
> >>>> Processing HomeController#index (for 190.39.201.34 at 2009-03-04
> >>>> 15:48:31) [GET]
> >>>> Session ID: 38521343127c98c9f14cb4c37492fe9c
> >>>> Parameters: {"action"=>"index", "controller"=>"home"}
> >>>> Redirected to /
> >>>> Filter chain halted as [:check_permissions] rendered_or_redirected.
> >>>> Completed in 5ms (DB: 3) | 302 Found [http://STRIPPED]
> >>>> Processing HomeController#index (for 190.39.201.34 at 2009-03-04
> >>>> 15:48:32) [GET]
> >>>> Session ID: 38521343127c98c9f14cb4c37492fe9c
> >>>> Parameters: {"action"=>"index", "controller"=>"home"}
> >>>> Redirected to /
> >>>> Filter chain halted as [:check_permissions] rendered_or_redirected.
> >>>> Completed in 4ms (DB: 2) | 302 Found [http://STRIPPED]
> >>>> The applications works properly in developer sandbox. Previous
> >>>> versions that was running now shows the same behaviour in the
> >>>> production server.
> >>>> The security setup is very simple, login and such hasn't been
> >>>> touched.
> >>>> --
> >>>> Aníbal Rojas
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Lovd by Less" 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 at
http://groups.google.com/group/lovdbyless?hl=en
Who loves ya baby?
-~----------~----~----~----~------~----~------~--~---
