HTTP Basic Auth

[Adam Zieliński]

Hi,

Simple question. I want to use HTTP Basic Auth to login to sync gateway. I use email as username. I tried to change @ from email to %40 but i received: Status reason: Unauthorized. 

Is it possible to log in to gateway using basic auth and email as user?

Adam.

[Jens Alfke]

How exactly are you doing the login?

—Jens

--
You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mobile-couchba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/918e1fda-ac9b-4a77-b93a-e0b233bddbf9%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Adam Zieliński]

I use this url:

http://username:password@hostname:4984/sync_gateway/

Adam

[Jens Alfke]

On Feb 11, 2014, at 12:41 PM, Adam Zieliński <azie...@gmail.com> wrote:

> I use this url:
> http://username:password@hostname:4984/sync_gateway/

What are you doing with the URL? Do you use it with Couchbase Lite (iOS or Android?), curl, … ?

If you want answers, giving enough detail is important.

—Jens

[Adam Zieliński]

Sorry for not enough information

I use phonegap plugin with couchbase lite (similar to todo lite app)

i use URL in remote properties:

var remote = {

 url : http://username:password@hostname:4984/sync_gateway/

},
push = {
 source : appDbName,
 target : remote,
 continuous : true
}
the same for pull. Then i use push and pull to call replication by http post.

Adam

[Jens Alfke]

On Feb 11, 2014, at 1:09 PM, Adam Zieliński <azie...@gmail.com> wrote:

I use phonegap plugin with couchbase lite (similar to todo lite app)

i use URL in remote properties:

OK, thanks. That code looks correct. 

When the login fails, the gateway should log a message like

HTTP auth failed for username="…"

Look for this and make sure that the username has been correctly decoded. If it's got "%40" in it or otherwise doesn't match the email address you expected, then please file an issue on Github, including the log line and what you expected the username to be.

—Jens

[Matt Ingenthron]

From: Adam Zieliński <azie...@gmail.com>
Reply-To: "mobile-c...@googlegroups.com" <mobile-c...@googlegroups.com>
Date: Tuesday, February 11, 2014 1:09 PM
To: "mobile-c...@googlegroups.com" <mobile-c...@googlegroups.com>
Subject: Re: HTTP Basic Auth

I use phonegap plugin with couchbase lite (similar to todo lite app)

i use URL in remote properties:

var remote = {
 url : http://username:password@hostname:4984/sync_gateway/
},

I'm not sure if it's relevant here, but while the username:password@ is relatively common and frequently does what you expect, it actually is not part HTTP standards.  I've seen some things that do not support it.  IIRC, it was removed and is recommended against in the HTTP URI scheme.

I can find the authoritative reference if needed, but just thought I'd mention it.

Matt

-- 

Matt Ingenthron

Couchbase, Inc.

[Jens Alfke]

On Feb 11, 2014, at 1:30 PM, Matt Ingenthron <ma...@couchbase.com> wrote:

I'm not sure if it's relevant here, but while the username:password@ is relatively common and frequently does what you expect, it actually is not part HTTP standards.  

It's defined in RFC 1738: Uniform Resource Locators, the specification of URL syntax:

3.1. Common Internet Scheme Syntax

   While the syntax for the rest of the URL may vary depending on the
   particular scheme selected, URL schemes that involve the direct use
   of an IP-based protocol to a specified host on the Internet use a
   common syntax for the scheme-specific data:

        //<user>:<password>@<host>:<port>/<url-path>

   Some or all of the parts "<user>:<password>@", ":<password>",
   ":<port>", and "/<url-path>" may be excluded.  The scheme specific
   data start with a double slash "//" to indicate that it complies with
   the common Internet scheme syntax.

I've seen some things that do not support it.  IIRC, it was removed and is recommended against in the HTTP URI scheme.

It's true that not all code out there that handles HTTP URLs checks for the username/password portion. But in the CouchDB replication API this is how you specify username/password based authentication, and the same goes for Couchbase Lite.

—Jens

[Matt Ingenthron]

Hi Jens,

Okay, you made me look it up.  :)

From: Jens Alfke <je...@couchbase.com>
Reply-To: "mobile-c...@googlegroups.com" <mobile-c...@googlegroups.com>
Date: Tuesday, February 11, 2014 1:36 PM
To: "mobile-c...@googlegroups.com" <mobile-c...@googlegroups.com>
Subject: Re: HTTP Basic Auth

On Feb 11, 2014, at 1:30 PM, Matt Ingenthron <ma...@couchbase.com> wrote:

I'm not sure if it's relevant here, but while the username:password@ is relatively common and frequently does what you expect, it actually is not part HTTP standards.  

It's defined in RFC 1738: Uniform Resource Locators, the specification of URL syntax:

RFC 2396 (which hails from 1998, where RFC 1738 seems to be from 1994, when most people hadn't yet used a URI) states:

3.2.2. Server-based Naming Authority

   URL schemes that involve the direct use of an IP-based protocol to a
   specified server on the Internet use a common syntax for the server
   component of the URI's scheme-specific data:

      <userinfo>@<host>:<port>

   where <userinfo> may consist of a user name and, optionally, scheme-
   specific information about how to gain authorization to access the
   server.  The parts "<userinfo>@" and ":<port>" may be omitted.

      server        = [ [ userinfo "@" ] hostport ]

   The user information, if present, is followed by a commercial at-sign
   "@".

      userinfo      = *( unreserved | escaped |
                         ";" | ":" | "&" | "=" | "+" | "$" | "," )

   Some URL schemes use the format "user:password" in the userinfo
   field. This practice is NOT RECOMMENDED, because the passing of
   authentication information in clear text (such as URI) has proven to
   be a security risk in almost every case where it has been used.

And if you don't consider the newer-ness important, the trump card in this case is this in RFC 2396:

This document updates and merges "Uniform Resource Locators"
   [RFC1738] and "Relative Uniform Resource Locators" [RFC1808] in order
   to define a single, generic syntax for all URI.

Just because CouchDB does it, doesn't mean it's correct.  I had this discussion with some of the CouchDB folks back in 2010 and it was acknowledged as an unfortunate choice in the face of what was an assumed standard.  I spoke up because I thought it might be relevant to be aware of the distinction.  

I know you know that just because CouchDB does it doesn't mean it's correct, since you've been awesome about documenting behavior and implementing questionable ideas for code compatibility.

I'm saying that something in between may be listening to 1998 URIs instead of 1994 URIs, stripping off the :password and sticking it in an authorization header for HTTP Basic auth.  IIRC, one version of Firefox did exactly that.  I don't have a reference for that one though, just seat-of-the-pants experience.

Thanks,

[Jens Alfke]

On Feb 11, 2014, at 2:38 PM, Matt Ingenthron <ma...@couchbase.com> wrote:

> Just because CouchDB does it, doesn't mean it's correct.

Specifically, it's including the password (not just the username) that's deprecated. However, I can't think of a better way in the REST API to provide the password. It could go into a separate parameter in the JSON settings, but that's just as insecure. (Actually in PhoneGap it isn't very insecure because that request never goes outside the app process.)

> I'm saying that something in between may be listening to 1998 URIs instead of 1994 URIs, stripping off the :password and sticking it in an authorization header for HTTP Basic auth.

That's exactly what the Couchbase Lite (and CouchDB) replicator do. If the destination URL contains a username or password, it strips it out and uses it for basic auth.

—Jens