Talk:Basic access authentication

message: I fail to see how this isn't contradictory :
Although the scheme is easily implemented, it relies on the assumption that the connection between the client and server computers is secure and can be trusted. Specifically, the credentials are passed as plain text and could be intercepted easily. The scheme also provides no protection for the information passed back from the server. To prevent the user name and password being read directly, they are encoded as a sequence of base-64 characters before transmission.
Is data encrypted or not?--Chealer 09:23, 2005 Jan 22 (UTC)
: I make the distinction between encoded and encrypted.  Encrypted implies that the data is either a hash that cannot be reversed, or can only be decoded with some form of private key.  As an example of encoded data, consider taking the letters of the password and shifting them one place in the alphabet, so Aladin becomes Bmbejo.  The base-64 encoding isn't really any harder to decode, it just means – as I've said in the article – that the user name and password cannot be read directly.  It provides no real security whatsoever, unlike digest access authentication.  — Lee J Haywood 09:54, 22 Jan 2005 (UTC)
thread_title:  encoded and encrypted 

message: Two questions:
First the easy one: Should this article be moved to Basic Authentication Scheme?  If not, should template:lowercase be dropped into the start of it?
Now the real question: Does password authentication in HTTPS use the same protocol?  If so, is it encrypted with the rest of the traffic?  Is that what the editor is getting at when calls for real encryption to be used? MrZaiustalk 04:01, 19 March 2007 (UTC)
replies: text: There is no compelling reason why the article title should be capitalised – see Wikipedia:Naming_conventions.  There is a big difference between authentication and encryption.  HTTPS itself most certainly does NOT rely on any authentication schemes, as it actually uses public-key cryptography to secure the entire request and response – including the URL.  I can only assume that the same authentication schemes are supported by HTTPS as with HTTP, but they are independent of it.  The comment about security is with regard to the password being passed essentially as 'plain text', such that anyone intercepting a request can read it.  With digest access authentication the password is never sent in the first place, but even that scheme has its limitations.  HTTPS does concern itself with 'authenticating' the site a browser connects to (via the use of certificates), but the basic authentication scheme relates to authenticating individual users (and potentially presenting different views of the web site to each person).  In practice, a lot of sites just have a HTML page with a user/password box which can be even less secure than the outdated digest access authentication scheme.  — Lee J Haywood 19:55, 19 March 2007 (UTC)
thread_title: caps and encryption

message: * Troubleshooting Basic Authentication on the Apache Web Server
This is not spam, I really like that article and recommend it to people all the time.. what do you guys think?
--Produke 09:02, 31 March 2007 (UTC)
replies: text: If you have a genuine link that is relevant then you should just add it yourself.  The page you have suggested doesn't seem specific to the article, however – I would suggest http://www.askapache.com/docs/2.0/howto/auth.html instead.  Thanks.  — Lee J Haywood 13:17, 31 March 2007 (UTC)
thread_title:  Link Suggestion 

message: HTTP response 401: Unauthorised or Unauthorized?  —The preceding unsigned comment was added by 192.54.144.229 (talk) 15:15, August 20, 2007 (UTC) 
: I spelt it the way it appears in my web servers.  The text is not used by the computer, and is only for reading by humans so both spellings are perfectly valid.  Thanks.  — Lee J Haywood 19:15, 20 August 2007 (UTC)
replies: text:  The spelling difference is due to international localization of language. I believe, and correct me if I'm wrong, that "Unauthorised" is the UK English spelling of it, while "Unauthorized" is the US English spelling. 71.104.146.63 (talk) 05:19, 25 April 2008 (UTC)
thread_title:  Spelling 

message: The line "One advantage of the basic access authentication is that it is supported by almost all popular web browsers." is questionable, but I'll submit it to talk.  I believe Basic Auth is supported by ALL popular web browsers.  I've never heard of one that doesn't support it and if there is one, I would wager it's certainly not popular.  Anyone have any examples of a popular web browser that doesn't support basic auth? JordanHenderson (talk) 23:08, 1 January 2008 (UTC)
replies: text: Assuming that "popular" is greater than .2% of the market share usage, than according to Comparison of Web Browsers, as retrieved just now, all "popular" web browsers support HTTP/1.1's basic authentication methods. The only one on the comparison list that does not is Mosaic, which only got to HTTP/0.9 support. As such, I will commit a change on the main page, as I believe that no one will ever find any such browser. (Wesley Spikes) 71.104.146.63 (talk) 05:26, 25 April 2008 (UTC)
thread_title:  Support by Web Browsers 

message: There is a way to implement logout:
The server has to send 401 for the realm ignoring the credentials. This will popup the login dialog in the browser again.
The implementation in JSP looks like this logout.jsp
<%
  if (null == session.getAttribute("__logout__seen")) {
    // if this page is invoked first, we send a login failure
    // so the browser prompts for user/password again
    response.addHeader("WWW-Authenticate", "Basic realm=\"your realm\"");
    response.sendError(401);
    // and we mark that we sent the 401
    session.setAttribute("__logout__seen", "yup");
  } else {
    // then we invalidate the session and redirect to the application
    session.invalidate();
    response.sendRedirect("index.html");
  }
%> 
User:StefanFranke  —Preceding undated comment added 09:22, 15 March 2009 (UTC)
thread_title:  Disadvantages 

message: The code sample supplied is not valid ANSI C, the encode_base64() and decode_base64() do not exist either in any C-related standard, nor does the syntax used look like the functions exist anywhere in this form at all. In any reasonable implementation, you would have to supply the output buffer as an argument to that function and normally also the length (for binary data).
212.66.157.114 (talk) 10:28, 3 September 2010 (UTC)
replies: text: Agreed. Removed.  --ChrisRuvolo (t) 21:30, 8 April 2011 (UTC)
thread_title:  ANSI C code sample 

message: Mention that one can use http://USER:PASSWORD@example.com/ URLs too, in many browsers, but not IE. Jidanni (talk) 02:28, 5 September 2010 (UTC)
thread_title:  user@password URLs 

message: I don't want to start an edit war, but this is inaccurate.  HTTP supports exactly one other methods of authentication, Digest access authentication.  There are numerous other authentication methods used over HTTP links, but Basic access authentication and Digest access authentication are the only two referenced in the HTTP Protocol documents, specifically in RFC2617
Other authentication schemes have been used involving interaction with a HTTP client and programs on an HTTP Server (sometimes involving Web Browser client side programming), but these aren't part of the HTTP protocol.  HTTPS supports authentication via X.509 Certificates, but HTTPS is a layer on top of HTTP.
I'm replacing this edit with another edit that highlights the two supported authentication methods in HTTP.JordanHenderson (talk) 03:11, 3 March 2011 (UTC)
thread_title:  There are many other methods of authentication in HTTP. ? 

message: Basic access authentication, in combination with SSL authentication, is a good way to provide a role based access to a resource.  The username can be used to establish the users role, while SSL certificates provide the authentication of the user.  Is this observation appropriate for this article?  Or is this more of a discussion topic for a forum somewhere? JordanHenderson (talk) 01:48, 20 August 2011 (UTC)
thread_title:  Role based access 

message: From the article. This collection is not encyclopedic and the different examples are almost all trivial and similar. I selected the PHP example to stay in the article (I don't use it myself so it's not such a bias, PHP selected for relative fame and use in relation to the web.) See []
-- Sverdrup (talk) 17:17, 14 October 2011 (UTC)
thread_title:  Unnecessary collection of trivial code examples. 

message: The resulting encoded string is not a string literal. A string literal is something typed directly into the source code, but the encoded string is computed (concatenate username, colon, password). Computed strings aren't literals.  — Preceding unsigned comment added by 24.234.119.49 (talk) 02:00, 26 September 2012 (UTC)
thread_title:  String literal? 

message: It is essential to give an example of a soap messaging containing basic authentication. How basic authentication manifest itself into static soap headers is not obvious; yet that is the subject and point of the article. In particular, are there predefined headers and/or value constraints. After some consideration, it seems the authentication headers must be included in every request and that this requirements distinguishes if from that which uses session cookies, following the initial handshake.  — Preceding unsigned comment added by 99.245.3.15 (talk) 03:40, 13 March 2013 (UTC)
thread_title:  Vague 

message: Looked biased towards IE  — Preceding unsigned comment added by 192.193.216.148 (talk) 04:08, 29 April 2015 (UTC)
thread_title:  Looked biased towards IE 

message: This article uses Template:HTTP.  However, the links from that template do not include a link to this article.  Shouldn't a link to it be included in the template? --Lance E Sloan (talk) 14:40, 12 May 2016 (UTC)
thread_title:  Add link for this article to Template:HTTP? 

message: I would suggest new title HTTP Basic access authentication in stead of Basic access authentication — Preceding unsigned comment added by Tech201805 (talk • contribs) 09:58, 24 May 2018 (UTC)
thread_title:  Title (adding HTTP adjective to be more descriptive)