Yes, but in both cases the security issue would be for someone to sniff the network. In this situation, both methods fail to provide security: HTTP Auth: - sniffer decodes username:password from the Base64 "Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==" header and can authenticate whenever he pleases. Token: - sniffer grabs the token and uses it himself to pose as the user. + user can call log out and the sniffer's access will be blocked out but the damage can already be done. - the sniffer can catch the initial log-in which sends the GET command with user name and password parameters which are in plain text. + If the authentication process involves more than one step (at least public/private keys or something stronger), the sniffer would not be able to find the user/pass and authenticate whenever he pleases. If we want good security, we need it done by an application on the client side. Another idea would be to use HTTP:// for anonymous access and HTTPS:// for authenticated access. Having HTTPS to secure the communication, the authentication approach could be a relatively simple one(please correct me), even token-based or basic auth. (seems curl handles HTTPS http://curl.netmirror.org/docs/manual.html) We should provide a standard way accessible both to a browser and a command-line tool like curl. WDYT? Pascal Voitot wrote:
On Mon, Dec 22, 2008 at 10:56 AM, Eduard Moraru <[email protected]>wrote:
Vincent Massol wrote:
On Dec 19, 2008, at 6:27 PM, Fabio Mancinelli wrote:
Vincent Massol wrote:
Does this mean I cannot open my browser and call the REST URL without specifying a user?
It should open up the authentication dialog where you type your username and password (or guest) the first time you request a resource.
Is that right? It sounds cumbersome and bad for easy automation when you want guest access.
Cannot we default to guest when no username/account is specified?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+1
User as a resource seems quite logical... this is the same point of view as OpenID...
I think it would be easier and more natural to have the default to guest or anonymous user. When an anonymous user tries to access restricted content -> 403 If he wants to log-in, he just does: http://user:[email protected]/space/X/page/Y
for security issues, passing the user/password for each request is really not very good... I really prefer the authentication token approach...
We should mimic the basic auth and skip the pop`ul window that requires user/pass in the browser.
That is: Imply that the current user is exactly who he says he is and do not assume he could be a user with rights to a resource until he explicitly says so. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs