Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pusher not properly setting headers on HTTP requests #687

Closed
dmunch opened this issue Jul 8, 2016 · 8 comments
Closed

Pusher not properly setting headers on HTTP requests #687

dmunch opened this issue Jul 8, 2016 · 8 comments
Labels
Milestone

Comments

@dmunch
Copy link

dmunch commented Jul 8, 2016

Hi,

we're currently looking into implementing a custom authorization scheme.

Basically, all we'd need to do is to send an Authorization Header with each request, however we're struggling in achieving this simple thing. Looking into the code it seems like ICustomHeadersAuthorizer should be the way to go, however all the interfaces in Couchbase.Lite.Auth seem to be internal.

I'm currently looking into re-packaging a custom version of Couchbase.Lite, however that's something I'd really like to avoid. So before getting my hands dirty I was wondering about two things:

  • Did I oversee something really simple?
  • Are there plans in making those interfaces public in the middle to long term?

I'd be more than happy in providing a helping hand and pull requests if necessary.

Thanks a lot in advance,
Daniel

@dmunch
Copy link
Author

dmunch commented Jul 8, 2016

Ok my college just came up with an ugly solution involving reflection.

var clientFactoryProperty = pushReplicator.GetType().GetTypeInfo().GetProperty("ClientFactory",   BindingFlags.Instance | BindingFlags.NonPublic);
var clientFactory = clientFactoryProperty.GetValue(push);
var HeadersProperty = clientFactory.GetType().GetTypeInfo().GetProperty("Headers",    BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public);
var headers = HeadersProperty.GetValue(clientFactory) as IDictionary<string, string>;
headers["Authorization"] = $"Bearer {bearerToken}";

This works, but is far from ideal. Maybe there's a hidden bug somewhere, since there actually is a property Headers in Replicator, however setting it has now effect.

@borrrden
Copy link
Member

borrrden commented Jul 9, 2016

Of course stuff using reflection will work but that means you are depending on implementation details. We don't offer a way to make authenticators like this, but the way you are doing it is exactly the same as our new OpenIDAuthenticator class. You can make a POST call using HttpWebRequest to Sync Gateway's _session endpoint and this will return a context to you (via a cookie) that you can set on the replicators.

I have made a sample for this on a branch, and you can see the flow starting here.

@borrrden
Copy link
Member

borrrden commented Jul 9, 2016

That being said, I just ran the unit test that tests the Headers property and it passed.

EDIT Ok that test only tests the puller. And you are using a pusher. I see the problem now. It's a very small fix, and you are lucky you reported today because code freeze is just in a couple of hours ;).

@borrrden borrrden changed the title Custom Authorization Pusher not properly setting headers on HTTP requests Jul 9, 2016
@borrrden borrrden added this to the 1.3 milestone Jul 9, 2016
@borrrden
Copy link
Member

Things should be fixed now, let me know in a day or two, or I'll be closing this ticket.

@dmunch
Copy link
Author

dmunch commented Jul 11, 2016

Thanks a lot for your fast response and action, this looks like it would resolve our issue. Is there an easy way for us to test this, like a private NuGet feed? Otherwise I'll just build and reference locally.

@borrrden
Copy link
Member

Get a build from our nightly build server

http://latestbuilds.hq.couchbase.com/couchbase-lite-net/

@dmunch
Copy link
Author

dmunch commented Jul 11, 2016

Perfect! Just tested, the headers which we set via Replicator.Headers are sent as expected now. Thanks again for the quick fix. Is there any estimation when 1.3 will ship ?

@borrrden
Copy link
Member

Estimated by the end of this month

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants