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

How to use with Authentication #29

Open
spawnia opened this issue Feb 20, 2018 · 8 comments
Open

How to use with Authentication #29

spawnia opened this issue Feb 20, 2018 · 8 comments

Comments

@spawnia
Copy link

spawnia commented Feb 20, 2018

Hi, i want to use Coloquent in my project - the syntax and ease of use look really nice.

My API requires Authentication via an Access Token sent in the Header. While looking through the source code of Model, i noticed that you are not exposing Axios options to the child class.

Am i missing something, is there an easy way to do this? If not, are there plans of exposing such configuration?

Thank you

@DavidDuwaer
Copy link
Owner

I'll release a fix tonight, it will basically come down to that you can inject your own AxiosInstance with a method setApiClient on Model.

@spawnia
Copy link
Author

spawnia commented Feb 20, 2018

Really cool, i will take a look once you have it and happily test it!

@kuzyk
Copy link

kuzyk commented Feb 23, 2018

Are any changes to this issue?

DavidDuwaer added a commit that referenced this issue Feb 23, 2018
…efault Axios) in a set of three interfaces,

- Allowing for dependency injection: anyone can implement these interfaces for their HTTP client of choice and inject it into Coloquent.
- Allowing for people to obtain the HTTP client from Coloquent through Model.getHttpClient().getImplementingClient(), without jeapardizing future backward-compatibility.
@DavidDuwaer
Copy link
Owner

DavidDuwaer commented Feb 23, 2018

I've addressed the issue and released the solution.

To protect future backward-compatibility, I first had to isolate Coloquent from the HTTP client it uses by wrapping the HTTP client (and its promise, and its response) in interfaces. You can now obtain the AxiosInstance from Model by doing
instanceOfModel.getHttpClient().getImplementingClient() (if using TypeScript you might wanna cast it to AxiosInstance). You can set its configuration in that object's .default property.

You can even inject any HTTP client now with instanceOfModel.setHttpClient, provided that you implement Coloquent's HttpClient, HttpPromise and HttpResponse interfaces for it.

@DavidDuwaer
Copy link
Owner

@spawnia @kuzyk Let me know if this solves your problem!

@spawnia
Copy link
Author

spawnia commented Apr 1, 2018

Thank you for taking the time to work on this. Your solution does work, and it offers a lot of flexiblity.

However, i think authentication via JWT or similar mechanisms is such a common use case and should probably be a first-class configuration option. It would be useful to have an example configuration, probably via a shared Model class, overriding the default configuration.

@andrewn
Copy link

andrewn commented Apr 24, 2018

I agree that it would be very useful to set the Authorization header (or some other custom headers) without needing to reimplement the HttpClient interface.

I currently can't see a way of setting the HTTP client at the collection fetching level? e.g. how would I make Artist.get() use the custom HttpClient?

@DavidDuwaer
Copy link
Owner

(Update to the new version (v1.0.2), the exposed HttpClient was not static on the Model class, causing a new client instance to be used for every model instance; this is now fixed.)

You can set the HTTP client headers by getting the "implementing client" instance, and setting the proeprty there. Since Coloquent by default has Axios, you can do it like this:

let axiosInstance: AxiosInstance = YourModel.getHttpClient().getImplementingClient();
axiosInstance.defaults.headers.authentication = 'someAuthenticationHeader5636rt3';

After setting this, the authorization header is set for all queries. We can make an API so you can set default headers directly on Model, I'm open to pull requests. Would be nice if the configuration methods are fluent as well (e.g. Model.setDefaultHeader('foo', 'value').setDefaultHeader('bar', 'value')). Also, do you need to be able to set it for specific requests? I can imagine a .header operator to be useful in a query.

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

No branches or pull requests

4 participants