Http Basic Auth

[PriceChild]

When basic auth is required on /tt-rss, loading /ttrss-mobile will also prompt for basic auth before showing you the standard login screen.

ttrss-mobile should either detect that an "Authorisation" header has been set or have a config setting in conf.js to require basic auth and use that rather than its login screen.

[mboinet]

I think that when you're using Basic Auth, you're in single mode. Is this the case?

This might be linked to issue #4.

[PriceChild]

No I am not using single user mode.

I'm using the auth_remote module to handle authentication then telling nginx to require basic auth for the /tt-rss directory.

I would imagine that if /ttrss-mobile also required basic auth, because of the requirement for it to be hosted at the same address the login could be gotten rid of completely. I'm going to have a butchers myself and maybe submit a pull request if I can figure something out.

[mboinet]

If I understand your setup well, you've got two authentication levels:

1. HTTP auth for any requests on /tt-rss
2. Tiny tiny RSS included authentication

I don't understand if you use HTTP auth for /ttrss-mobile or not. If yes, do they share the same protection space (realm)? (http://www.ietf.org/rfc/rfc2617.txt)

[PriceChild]

I have one layer, all requests within /tt-rss must contain a valid
authorization header.

Tt-tss has only the 'auth_remote, module loaded, not the 'auth_internal'
one. This means that when you visit it with a valid 'remote_user' header
(set by the webserver) tt-rss bypasses the login screen and just takes you
to your feeds.

I currently have nothing special set on /ttrss- mobile. Is current seems to
immediately trigger a request to tt-rss's a pi which causes the browser to
display the basic auth dialogue. If you enter valid credentials you then
see /ttrss-mobile's own superfluous login page.

I don't want to log in twice... So yes sorry I think you're right... I
would assume any setting allowing the login page of /ttrss-mobile to be
disabled would solve the problem. I guess then it could be solved with the
solution to issue #4
On 18 Mar 2013 17:24, "mboinet" [email protected] wrote:

If I understand your setup well, you've got two authentication levels:

1. HTTP auth for any requests on /tt-rss
2. Tiny tiny RSS included authentication

I don't understand if you use HTTP auth for /ttrss-mobile or not. If yes,
do they share the same protection space (realm)? (
http://www.ietf.org/rfc/rfc2617.txt)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/12#issuecomment-15068495
.

[mboinet]

I need to reproduce your problem but I think this is linked to issue number #4 . The webapp needs to authenticate with the API to get a valid session. If I try to have a valid session with empty credentials on first try it might work in your situation.

So you have to wait or you can try to work on a patch ;-)
I'll keep you updated if I start to work on this but I don't think it'll be in the coming week.

[mboinet]

Could you test now with this commit 495f264?

[PriceChild]

I'm afraid that doesn't seem to work. It still gives a login page.

I tried with /ttrss-mobile and /tt-rss requiring auth and only /tt-rss
needing auth.

On 27 March 2013 20:50, mboinet [email protected] wrote:

Could you test now with this commit 495f264495f264
?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/12#issuecomment-15552324
.