User Management.

[CouchbaseLover]

Hey again! 

We've used Couchbase for around 8 months and just upgraded to 3.1. What we have left until release is channels/user authentication, but we have run into alot of problems. 

We have written our own API over your CBL and it's based on your "old" structure(Beta 1?). We think the best documentation/help is to just look in the examples/projects and we like the way ToDoLite iOS is written and would like to "use that code" in our project to fix user channels/user authentication, is this a good idea? 

Have a great day! 

// CouchbaseLover

[J. Chris Anderson]

I'm glad you enjoy the code. We are happy for you to use it -- it's meant to embody an 80% solution for "groupware" style sharing. Feel free to post snippets here if you have questions.

Chris

[CouchbaseLover]

Hey ! :) 

I changed so ToDoLite would work on our server instead of yours with success, except sharing the "lists" didn't work ? But we get the right documents in our todo bucket - sync user/sessions and so forth. Why is this? 

I tried to replicate this "user management" you got in ToDoLite but without fb login and instead create a user account/session with the sync gateway API ( custom authentication etc) with success. I get the right response ""session_id":"dfb15cf5183cc9a2bc7966141f3c595c744bc47e","expires":"2014-04-23T09:24:49.290396472+02:00","cookie_name":"SyncGatewaySession"  and the right documents in the bucket (24 hours sessions).

  "id": "c55604b470baa8ce1f79d54b5cba64b3332430cc",

  "username": "t...@tt.tt",

  "expiration": "2014-04-23T09:49:15.737043674+02:00"

What's the next step? The sync function has guest disabled, but the app still asks for login (running the app) and we get still get the "401 Login required  (0.0 ms)" error. 

The "GUEST": {"disabled": true 

Summarize: This is the first time we're actually not just Guests (Guest disabled:false) but real USERS in the app with sessions. Now is the time to build up sync functions around access(channels)/requireuser(wealllovecouchbase) to prevent the Login Required error? 

Best Regards

Couchbaselover

[Jens Alfke]

On Apr 22, 2014, at 1:11 AM, CouchbaseLover <sharess...@gmail.com> wrote:

I changed so ToDoLite would work on our server instead of yours with success, except sharing the "lists" didn't work ? But we get the right documents in our todo bucket - sync user/sessions and so forth. Why is this? 

Sounds like an issue with the sync function. Did you copy the sync function from the original gateway’s config into yours?

I tried to replicate this "user management" you got in ToDoLite but without fb login and instead create a user account/session with the sync gateway API ( custom authentication etc) with success. 

Great. I don’t use Facebook myself, so I’d love it if ToDoLite could use username/password auth.

What's the next step? The sync function has guest disabled, but the app still asks for login (running the app) and we get still get the "401 Login required  (0.0 ms)" error. 

Not quite sure what you’re asking; in the client app are you setting the credentials of the CBLReplication object? For example,

repl.credential = [NSURLCredential credentialWithUser: username password: password persistence: NSURLCredentialPersistenceForSession];

You can also embed the username/password directly in the replication URL if you want, like

http://username:pass...@host.com:4984/db/

—Jens

[Jens Alfke]

On Jun 10, 2014, at 1:58 AM, CouchbaseLover <sharess...@gmail.com> wrote:

"You can also embed the username/password directly in the replication URL if you want, like

http://username:password@host.com:4984/db/"

Is this really secure though? 

The URL in that form never leaves your device. Remember, HTTP doesn’t directly send URLs. What shows up in the request is like

GET /db HTTP/1.1

Host: host.com:4984

WWW-Authenticate: ….base64….

It’s true that HTTP basic auth itself is insecure, because it’s trivial to read the username and password from the value of the WWW-Authenticate: request header. That’s why you shouldn’t use basic auth except over SSL. But this has nothing to do with whether you embed the username/password in the URL.

—Jens

[CouchbaseLover]

Another month have passed and we just realised that all the Authentication works just fine if we SET continuous to FALSE, now we can PUT/GET and all that. Tried looking at your update on CouchChat with the User Management and we can't see what makes your app not failing with continuous, any ideas why ours is not working?

1.  Why is it working differently if you set it to continuous false/true when it comes to User Management ? 

// CouchbaseLover

[Jens Alfke]

On Jun 13, 2014, at 10:35 AM, CouchbaseLover <sharess...@gmail.com> wrote:

1.  Why is it working differently if you set it to continuous false/true when it comes to User Management ? 

I don’t know. The main difference is the way the _changes feed gets requested, so there may be some issue with auth there.

Can you describe what exactly is going wrong in your app when you use continuous replication?

—Jens

[CouchbaseLover]

#3763: GET /horse/_changes?feed=websocket

23:38:29.922535 HTTP: #3763:     --> 401 Login required  (0.0 ms

No clue what's "going wrong" cause we have no idea what the process should be..

1. POST request to /$DB/_user/. -> Successfull, we have a sync user now.

2. NSURLCredential *cred = [NSURLCredential

                             credentialWithUser: xxxx

                             password:xxxx

                             persistence: NSURLCredentialPersistencePermanent];

    NSLog(@"cred = %@", cred);

NSURLProtectionSpace* space;

    space = [[NSURLProtectionSpace alloc]

             initWithHost: @"http://xxxx"

             port: xxxx

             protocol: @"https"

             realm: @"xxxx"

             authenticationMethod: NSURLAuthenticationMethodDefault];

    NSLog(@"space = %@", space); 

    [[NSURLCredentialStorage sharedCredentialStorage] setDefaultCredential: nil forProtectionSpace: space];

- The realm is correct yes.

3. Create session for user trough Custom (Indirect) Authentication protocol.

 The session "documents" looks correct and the response is successfull.

//CouchbaseLover

[Jens Alfke]

On Jun 13, 2014, at 3:54 PM, CouchbaseLover <sharess...@gmail.com> wrote:

> #3763: GET /horse/_changes?feed=websocket
> 23:38:29.922535 HTTP: #3763: --> 401 Login required (0.0 ms
> No clue what's "going wrong" cause we have no idea what the process should be..

CBL is using a WebSocket to connect to the continuous _changes feed, and it looks like the credentials aren't getting sent along with that request for some reason, so it gets a 401 error. This could be a CBL bug, but to diagnose it I need to know how you’re authenticating the CBLReplication.

I’m not clear on how you’re setting up authentication. First you show code for configuring a username/password with NSURLCredential, but then in step 3 you say you’re creating a session cookie through a custom protocol to your application server. Those shouldn’t both be necessary. And once you get the session cookie from the app server, what’s the code you’re using to register it with the CBL replication?

—Jens

[CouchbaseLover]

Scratch the part 3, we've got it to work without that..i just wanted to mention that, no clue why i did that.

1. We post a user to the server. /$DB/_user/

2. We do the exact same stuff that you do in CouchChat - NSURLCredential = repl.credential

I'm just really confused right now, been working non-stop to trying to make this work and i just don't get it :(

Do you even post a user to the server? 

Seems like the only thing your doing is - NSURLCredentials *cred without the need of NSURLProtectionSpace
 and then just put CBLReplcation.credentials = cred. You don't even post a user to the server (/$DB/_user/)?

Where is your session? And how could our logic work fine when continuous is false, is it because you don't need a session when it's set to false? 

Sorry for my bad grammar, and i really do appreciate you trying and giving me quick response :)

//CouchbaseLover

[Jens Alfke]

On Jun 13, 2014, at 5:26 PM, CouchbaseLover <sharess...@gmail.com> wrote:

1. We post a user to the server. /$DB/_user/

Um wait — you do this from the app? That’s part of the Sync Gateway admin API … if you’re making the admin API publicly accessible, you’re giving anyone in the world the ability to do anything to your database (what CouchDB calls an “admin party”.) You definitely don’t want to do that in real life.

Seems like the only thing your doing is - NSURLCredentials *cred without the need of NSURLProtectionSpace
 and then just put CBLReplcation.credentials = cred.

Right. All you need to do is tell the replication object the username/password to use.

Where is your session?

There isn’t one; it’s just using HTTP Basic auth, i.e. passing the username/password with each request.

—Jens

[CouchbaseLover]

Are you using persona for authentication/sessions in CouchChat? And i see in the Gateway your using walrus...

It didn't work at all just doing NSURLCredential + repl.credentials, now we're back to square one :)

13:36:23.143512 HTTP auth failed for username="z...@za.za"

13:36:23.143626 HTTP: #3814:     --> 401 Invalid login  (0.0 ms)

We have a presentation next week and we can't even get normal email login to work lol. Just seems like everything is problems problems problems,  we can't even check what you did with CouchChat. It doesn't compile at all after the normal git clone + git submodule init + submodule update, after that you have a bunch of errors. Right now im doubting if it's been worth spending more then a year now trying to get CouchBase to work with even the most basic stuff.

CouchbaseLover.(Maybe i should change my name now lol)

[Jens Alfke]

On Jun 14, 2014, at 5:23 AM, CouchbaseLover <sharess...@gmail.com> wrote:

Are you using persona for authentication/sessions in CouchChat?

Yes. Maybe that doesn’t match what you want, but you’re the one who brought up CouchChat :)

It would be a lot easier to help you out if you would describe in detail how you want authentication to work.

And i see in the Gateway your using walrus…

Walrus vs. Couchbase Server has no effect on the client at all. It’s just that Walrus is easier to configure.

It didn't work at all just doing NSURLCredential + repl.credentials, now we're back to square one :)

13:36:23.143512 HTTP auth failed for username="z...@za.za"

13:36:23.143626 HTTP: #3814:     --> 401 Invalid login  (0.0 ms)

Well, did you create an account on the server first?

I’m also confused how you’ve gotten this far (and a year of development time) without implementing login?

Just seems like everything is problems problems problems,  we can't even check what you did with CouchChat. It doesn't compile at all after the normal git clone + git submodule init + submodule update, after that you have a bunch of errors.

I just updated it a few days ago to work with 1.0. I know several other people have built it successfully since then.

Again, it would be easier to help if you’d describe what exactly the errors are.

—Jens

[CouchbaseLover]

First off i think an apology is in order, sorry for my behaviour :) I really do appreciate all you've done and behaving very professionally, opposite from me.

It would be a lot easier to help you out if you would describe in detail how you want authentication to work.

Truth to be told i don't really know exactly how i want the authentication to work as i don't know how it/what works.

The end result is that we want a simple Login/Register with Email&Password and that works with continuous.

Now what do you mean with:

Well, did you create an account on the server first?

Ok so to really succeed i think you need to tell me what's needed to make it work from A-Z with Email&Password + continuous if you don't mind.

Best Regards

Thanks for responding on a weekend.

//CouchbaseLover 

[Jens Alfke]

On Jun 14, 2014, at 11:52 AM, CouchbaseLover <sharess...@gmail.com> wrote:

First off i think an apology is in order, sorry for my behaviour :)

Thanks for apologizing; all forgiven :) I understand the kind of frustration you’re having.

The end result is that we want a simple Login/Register with Email&Password and that works with continuous. ...

Ok so to really succeed i think you need to tell me what's needed to make it work from A-Z with Email&Password + continuous if you don't mind.

OK. I outlined this on another thread but I’ll go into more detail here. The short answer is that if you want to register username/password accounts you’ll need to write a small bit of server-side code to do it.

Registration:

1. User enters desired credentials in your app’s UI.
2. App sends these to a custom server-side script, probably via a POST.
3. Server-side script calls the Gateway’s admin API with a PUT /db/username to register the user.

Login:

1. App prompts user for username/password.

2. App creates an NSURLCredential with the username/password, sets its persistence to permanent, and registers it with the NSURLCredentialStore.

At launch time:

1. If this is the first launch, prompt the user to register or log in.
2. Otherwise, start replications, adding observers to watch their status.
3. If replication fails with a 401 status, run the login phase again.

Does that make sense? As I said earlier, step 3 of Registration is the only custom server-side code you need to write, and it’s pretty simple.

Eventually it would be good to add registration to the Gateway as a feature.  Looking back, I think the reasons we didn’t add it in 1.0 are (a) enterprise users don’t need it, and (b) a lot of people (like me) hate registering yet another username and password to use an app, so a solution like Persona seems a much better alternative.

—Jens

[CouchbaseLover]

I couldn't of asked for a better response, i feel much more calm now. I just wanted someone to clarify so we didn't make any extra logic, that wasn't really needed cause it was already implemented by Couchbase.

Im getting more impressed by the day by all your support. You can tag this "thread" as "closed".

Regards

//CouchbaseLover

[J. Chris Anderson]

On Saturday, June 14, 2014 2:34:53 PM UTC-7, Jens Alfke wrote:

On Jun 14, 2014, at 11:52 AM, CouchbaseLover <sharess...@gmail.com> wrote:

First off i think an apology is in order, sorry for my behaviour :)

Thanks for apologizing; all forgiven :) I understand the kind of frustration you’re having.

The end result is that we want a simple Login/Register with Email&Password and that works with continuous. ...

Ok so to really succeed i think you need to tell me what's needed to make it work from A-Z with Email&Password + continuous if you don't mind.

OK. I outlined this on another thread but I’ll go into more detail here. The short answer is that if you want to register username/password accounts you’ll need to write a small bit of server-side code to do it.

Registration:

1. User enters desired credentials in your app’s UI.
2. App sends these to a custom server-side script, probably via a POST.
3. Server-side script calls the Gateway’s admin API with a PUT /db/username to register the user.

I think Jens means /db/_user/username 

I agree it would be cool to have more support for sign-up built into Sync Gateway.