Caldavzap/mate auth using basic_auth
Hi! I'm using apache basic_auth on my webserver that runs Davical and caldavzap/mate. While caldavzap doesn't seem to be negatively affected by basic_auth, unfortunately it doesn't take advantage of it either. In theory it could skip the login screen and jump right into the calendar. Instead one has to enter his credentials again. "/auth/" shows that caldavzap correctly receives username/password from the webserver (even when not "logged in" in caldavzap). Is there a way to make caldavzap (and *mate) to skip the login-screen in such a setup? cheers Dariush
Hi Dariush, On 04 May 2014, at 21:03, Dariush Forouher <dariush@forouher.de> wrote:
Hi!
I'm using apache basic_auth on my webserver that runs Davical and caldavzap/mate.
While caldavzap doesn't seem to be negatively affected by basic_auth, unfortunately it doesn't take advantage of it either. In theory it could skip the login screen and jump right into the calendar. Instead one has to enter his credentials again.
no, basic auth is not related to "fast login" or anything similar. Basic auth = authentication where your username and password is send in the request header without encryption. Another authentication is the Digest auth which uses multiple request/responses and sends your password in hashed form. There is no real reason to use Digest auth because if you really want to secure your data then you need to use SSL/TLS (and then you can send the authentication information without additional encryption). For more information see: https://www.ietf.org/rfc/rfc2617.txt
"/auth/" shows that caldavzap correctly receives username/password from the webserver (even when not "logged in" in caldavzap).
No, the auth module cannot return the username/password if you are not logged in. You very probably entered your username + password into the browser authentication window and saved them. Then if you open the /auth/ URL your browser sends the username + password automatically.
Is there a way to make caldavzap (and *mate) to skip the login-screen in such a setup?
It looks like you don't understand the reason why the auth module exists. The MAIN reason is to prevent the browser to show the auth popup if you enter invalid username/password into the login windows (because this problem is no solvable in pure JavaScript). For more information check the section 6.) at: https://www.inf-it.com/caldavzap/readme.txt JM
cheers Dariush
Hi Ján!
I'm using apache basic_auth on my webserver that runs Davical and caldavzap/mate.
While caldavzap doesn't seem to be negatively affected by basic_auth, unfortunately it doesn't take advantage of it either. In theory it could skip the login screen and jump right into the calendar. Instead one has to enter his credentials again.
no, basic auth is not related to "fast login" or anything similar. Basic auth = authentication where your username and password is send in the request header without encryption. Another authentication is the Digest auth which uses multiple request/responses and sends your password in hashed form.
Yes, I'm using Basic Auth over TLS: apache config: [...] AuthType Basic AuthName "My secret area" [...] You're right, it doesn't offer anything like "fast login" (the user still has to enter her password, just in a popup window presented by the browser). What Basic Auth *does* offer is a simple way to achieve single-sign-on across wildly different web applications, as the browser will cache the credentials during its runtime.
"/auth/" shows that caldavzap correctly receives username/password from the webserver (even when not "logged in" in caldavzap).
No, the auth module cannot return the username/password if you are not logged in. You very probably entered your username + password into the browser authentication window and saved them. Then if you open the /auth/ URL your browser sends the username + password automatically.
Yes, precisely.
Is there a way to make caldavzap (and *mate) to skip the login-screen in such a setup?
It looks like you don't understand the reason why the auth module exists. The MAIN reason is to prevent the browser to show the auth popup if you enter invalid username/password into the login windows (because this problem is no solvable in pure JavaScript).
Yeah, the concept of the auth module is a bit fuzzy to me, and maybe it doesn't have anything to do with what I try to achieve (i.e., make caldavzap somehow acquire the credentials provided by the browser). How I understand caldavzap is that it is running partially as PHP on the server and partially in the browser as JS. I don't have much experience with JS-based apps like this. Old-school web applications like PHP-based ones could easily be modified to make use of the PHP_AUTH_* variables so that they would skip their login-screen. I'd like to do the same with caldavzap. As caldavzap seems to run primarily as JS in the browser, it obviously doesn't have access to the PHP_AUTH_* environment variables. I just wonder whether you might know a way to make this work regardless. regards Dariush
On 05 May 2014, at 08:22, Dariush Forouher <dariush@forouher.de> wrote:
Hi Ján!
I'm using apache basic_auth on my webserver that runs Davical and caldavzap/mate.
While caldavzap doesn't seem to be negatively affected by basic_auth, unfortunately it doesn't take advantage of it either. In theory it could skip the login screen and jump right into the calendar. Instead one has to enter his credentials again.
no, basic auth is not related to "fast login" or anything similar. Basic auth = authentication where your username and password is send in the request header without encryption. Another authentication is the Digest auth which uses multiple request/responses and sends your password in hashed form.
Yes, I'm using Basic Auth over TLS:
apache config: [...] AuthType Basic AuthName "My secret area" [...]
You're right, it doesn't offer anything like "fast login" (the user still has to enter her password, just in a popup window presented by the browser).
What Basic Auth *does* offer is a simple way to achieve single-sign-on across wildly different web applications, as the browser will cache the credentials during its runtime.
You are partially right :-) ... the problem is that this approach works well for basic web sites, but not for JavaScript *applications*. If a web application needs to send username+password directly in the request, then it simply needs to know the username/password (and it cannot read these from the browser /there is no API for that/).
"/auth/" shows that caldavzap correctly receives username/password from the webserver (even when not "logged in" in caldavzap).
No, the auth module cannot return the username/password if you are not logged in. You very probably entered your username + password into the browser authentication window and saved them. Then if you open the /auth/ URL your browser sends the username + password automatically.
Yes, precisely.
Is there a way to make caldavzap (and *mate) to skip the login-screen in such a setup?
It looks like you don't understand the reason why the auth module exists. The MAIN reason is to prevent the browser to show the auth popup if you enter invalid username/password into the login windows (because this problem is no solvable in pure JavaScript).
Yeah, the concept of the auth module is a bit fuzzy to me, and maybe it doesn't have anything to do with what I try to achieve (i.e., make caldavzap somehow acquire the credentials provided by the browser).
How I understand caldavzap is that it is running partially as PHP on the server and partially in the browser as JS. I don't have much experience with JS-based apps like this. Old-school web applications like PHP-based ones could easily be modified to make use of the PHP_AUTH_* variables so that they would skip their login-screen.
No, CalDavZAP is pure JavaScript application, but it has one major limitation: if it sends the username+password directly to the *DAV server and these credentials are invalid, then your browser shows the auth popup window (because it handles the WWW-Authenticate: response header) what breaks the consistency of the GUI. There are 2 possible solutions for this problem: 1.) do no send the "WWW-Authenticate:" header if the client is CardDavMATE or CalDavZAP (X-Client header) ... this approach requires changes on server side 2.) create a "proxy" module, which sends username+password to the *DAV server and if the authentication is unsuccessful it NOT returns the "WWW-Authenticate:" header back to the client (=> no auth popup); the login process (only the login process) then looks like: Client => Auth module => Server
I'd like to do the same with caldavzap. As caldavzap seems to run primarily as JS in the browser, it obviously doesn't have access to the PHP_AUTH_* environment variables. I just wonder whether you might know a way to make this work regardless.
As I mentioned earlier there is no way to get the username/password from the browser back to the JavaScript. And if you don't know the username, then you there is no principal URL => it will not work. What you can try is: 1.) use the globalAccountSettings option with empty ('') username+password and href option set to principal URL with invalid user part (such as "xxx") and then use rewrite rules on server side and replace the "xxx" username (from the auth variables) before the request reaches the *DAV server 2.) change the source code and perform the request to the auth module without requiring click to the "Login" button. The reason why there is no such option is that I really hate it, because of the stupid implementation of the basic auth by browsers (there is no way to logout without browser restart) JM
regards Dariush
Hi. On Mon, May 05, 2014 at 09:07:18AM +0200, Ján Máté wrote:
No, CalDavZAP is pure JavaScript application, but it has one major limitation: if it sends the username+password directly to the *DAV server and these credentials are invalid, then your browser shows the auth popup window (because it handles the WWW-Authenticate: response header) what breaks the consistency of the GUI. With Firefox, you can try to issue a XHR with mozBackgroundRequest = true. cf. https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest
2.) change the source code and perform the request to the auth module without requiring click to the "Login" button. The reason why there is no such option is that I really hate it, because of the stupid implementation of the basic auth by browsers (there is no way to logout without browser restart)
This is not true. Firefox let's you do this via Ctrl+Shift+Del (cf. <http://superuser.com/a/181554/265964>). There is a bug report for having a more native UI, though: <https://bugzilla.mozilla.org/show_bug.cgi?id=300002> Cheers, Tobi
Hi Tobias, it is nice that at least Firefox tries to fix these issues, but until these features are not supported at least by Gecko + Webkit browsers (FF + Chrome, Safari, ...) there is no reason to use them. I am not interested in ton of support questions/requests why something works in one browser and not in others ... JM On 05 May 2014, at 10:17, Tobias Mueller <muelli@cryptobitch.de> wrote:
Hi.
On Mon, May 05, 2014 at 09:07:18AM +0200, Ján Máté wrote:
No, CalDavZAP is pure JavaScript application, but it has one major limitation: if it sends the username+password directly to the *DAV server and these credentials are invalid, then your browser shows the auth popup window (because it handles the WWW-Authenticate: response header) what breaks the consistency of the GUI. With Firefox, you can try to issue a XHR with mozBackgroundRequest = true. cf. https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest
2.) change the source code and perform the request to the auth module without requiring click to the "Login" button. The reason why there is no such option is that I really hate it, because of the stupid implementation of the basic auth by browsers (there is no way to logout without browser restart)
This is not true. Firefox let's you do this via Ctrl+Shift+Del (cf. <http://superuser.com/a/181554/265964>). There is a bug report for having a more native UI, though: <https://bugzilla.mozilla.org/show_bug.cgi?id=300002>
Cheers, Tobi
Hi. On Mon, May 05, 2014 at 10:31:56AM +0200, Ján Máté wrote:
it is nice that at least Firefox tries to fix these issues, but until these features are not supported at least by Gecko + Webkit browsers (FF + Chrome, Safari, ...) there is no reason to use them. I don't agree with that sentiment, but everbody has their preferences...
In any case, it seems your assessment of the Web browsers handling the HTTP authorization header is incomplete, cf. http://codereaper.com/bugspray/javascript/xmlhttprequest/httpauthentication/ and https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#the-send%28%29-method If authentication fails, source origin and the request URL are same origin, Authorization is not in the list of author request headers, request URL's username is the empty string and request URL's password is null, user agents should prompt the end user for their username and password. Otherwise, if authentication fails, user agents must not prompt the end user for their username and password. Cheers, Tobi
On 05 May 2014, at 11:38, Tobias Mueller <muelli@cryptobitch.de> wrote:
Hi.
On Mon, May 05, 2014 at 10:31:56AM +0200, Ján Máté wrote:
it is nice that at least Firefox tries to fix these issues, but until these features are not supported at least by Gecko + Webkit browsers (FF + Chrome, Safari, ...) there is no reason to use them. I don't agree with that sentiment, but everbody has their preferences...
In any case, it seems your assessment of the Web browsers handling the HTTP authorization header is incomplete, cf. http://codereaper.com/bugspray/javascript/xmlhttprequest/httpauthentication/ and https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#the-send%28%29-method
If authentication fails, source origin and the request URL are same origin, Authorization is not in the list of author request headers, request URL's username is the empty string and request URL's password is null, user agents should prompt the end user for their username and password.
Otherwise, if authentication fails, user agents must not prompt the end user for their username and password.
The problem is that JavaScript client differs from the standard browser behaviour. If you open a web site protected by basic auth then you make a request, get the "WWW-Authenticate" header and then send your credentials. With JavaScript you simply sends the request directly with the Authorization header (without making a prior request) and if the authorization fails then you get the "WWW-Authenticate" header in the response ... It is maybe not compliant with the specification(s) (I don't know) but it simply works this way (real world experience) ... JM
Cheers, Tobi
Am 05.05.2014 10:17, schrieb Tobias Mueller:
(there is no way to logout without browser restart)
This is not true. Firefox let's you do this via Ctrl+Shift+Del (cf. <http://superuser.com/a/181554/265964>).
Nice, I did not know that. :) cheers Dariush
Hi Ján, Am 05.05.2014 09:07, schrieb Ján Máté:
2.) change the source code and perform the request to the auth module without requiring click to the "Login" button. The reason why there is no such option is that I really hate it, because of the stupid implementation of the basic auth by browsers (there is no way to logout without browser restart)
Good idea, that worked: <main.js> function loadConfig() { if(isUserLogged)// !!!!!! kedy moze toto nastat? nexapem ... return false; + + netLoadConfiguration(globalNetworkAccountSettings); + return true; var configLoaded=true; // Automatically detect crossDomain settings </main.js> You're right, not being able to log out is an annoying missing feature of browsers. But I never log out anywhere anyway, so this will work out fine. ;) Thanks for your help! cheers Dariush
participants (3)
-
Dariush Forouher -
Ján Máté -
Tobias Mueller