Once a user has authenticated in the browser, they can type in any username/password on login screen

[TwoHanded@…]

Once the user has authenticated in their browser, they are taken to the /login page. There, if they type in a DIFFERENT username and ANY password on the /login page, then they are logged in as that user.

The biggest problem with this is that on the /login screen if you type in a valid username, then you can use ANY password and it will allow you to login.

I am hoping that this is just a problem with my configuration My python skills are slim, or I would try to jump in and figure it out.

Thanks for your help!

[adeason@…]

Hmmm, I cannot replicate this here. Can you check your webserver logs, and see if the requests to the HTTP authentication URL are being made properly?

I'm also wondering why users would be taken to the /login page after they login. After they have successfully logged in, they are supposed to be redirected to the page they initially came from. If they are just sent back to the login box again, try looking at the HTML source and see if you see a hidden input element called "ref", and see what it's value is. It's supposed to be the URL of the page that the user is redirected back to when they've successfully authenticated.

After I saw this, though, I realized that if that input element is not set, the user is redirected to... somewhere (possibly the domain root?). Whatever req.redirect() redirects the user to when it's null. I'm attaching a patch that instead redirects the user to the project main page if the referer was not given.

[adeason@…]

Patch to redirect a user to the project main page upon successful authentication if the page referer is unknown.

[Noah Kantrowitz]

(In [745]) Trying to fix #346.

[Noah Kantrowitz]

Patch applied in [745]. Thanks.

[TwoHanded@…]

Thanks alot for the quick response.

I will try the patch to see if that helps, although it looks like it was designed to fix a different issue. And I will also take a look at the HTML that is rendered. One thing that I forgot to mention is that I am using tracd, so therefore, there aren't any webserver logs to help me troubleshoot what was going on. Is there any type of other logging that I can do or provide to help troubleshoot this issue when using tracd?

Thanks again!

I didn't want to reopen this issue, so I just added you both to the "CC" - I hope that is standard procedure.

[Noah Kantrowitz]

This wasn't meant to be closed actually, looks like the post-commit script did it.

[adeason@…]

I've never used tracd, so I don't know a lot about it... but can it actually make a certain URL use HTTP auth? What does it even authenticate against?

[anonymous]

Here's some info about tracd: ​http://projects.edgewall.com/trac/wiki/TracStandalone including information about authentication.

By default, Tracd provides support for Digest authentication using an htdigest file. Like I mentioned, I can get the authentication to work, that's not a problem. The problem is that once the user is authenticated they can then login as ANY user on the /login page.

[adeason@…]

There is the standard logging for trac, I remember... have you tried looking at the DEBUG messages from there? No idea if that shows something like an access log or something.

​http://projects.edgewall.com/trac/wiki/TracLogging

[Noah Kantrowitz]

I don't think this will actually work very well on tracd, as I would guess it hardcodes some of the auth paths.

[Noah Kantrowitz]

Plugin is deprecated.