0xMatt / ngx-oauth-client

An Angular4+ compatible OAuth2.0 compliant HTTP wrapper.
https://0xMatt.github.io/ngx-oauth-client
MIT License
39 stars 9 forks source link

Upgrade to Angular 5? #10

Closed masiorama closed 6 years ago

masiorama commented 6 years ago

Is it possibile to upgrade the package to angular 5?

0xMatt commented 6 years ago

PR #9 seems to try to address this, but last I saw tests were failing. I will see about fixing those tests tonight.

BlackTurtle123 commented 6 years ago

Is this update already done? This project still alive?

0xMatt commented 6 years ago

@BlackTurtle123, I've been using the project within my angular 5 app and haven't noticed any issues. Do we have any specific problem to address? I'm going to see about closing the current PR to upgrade to ng5 and create a new one myself once we get an idea of what exactly needs to be updated.

0xMatt commented 6 years ago

To add, this project is very much alive. I use it in all my applications but haven't had the need for anything complex outside of what the library provides. Once my persona projects settle down I'll be dedicating more time into adding features I just haven't really gotten any suggestions yet.

BlackTurtle123 commented 6 years ago

Hello I was just wondering since I might soon use and implement this plugin for my project. I don't have many Angular knowledge at this moment, but will probably use this project. Or try at least.

2018-03-09 21:53 GMT+01:00 Matthew Javelet notifications@github.com:

To add, this project is very much alive. I use it in all my applications but haven't had the need for anything complex outside of what the library provides. Once my persona projects settle down I'll be dedicating more time into adding features I just haven't really gotten any suggestions yet.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/0xMatt/ngx-oauth-client/issues/10#issuecomment-371942026, or mute the thread https://github.com/notifications/unsubscribe-auth/APS3aGaZ02gEgrizorXrfaxw89DgCAY2ks5tcuvPgaJpZM4Quu1r .

0xMatt commented 6 years ago

@masiorama, @BlackTurtle123. Thank you for your patience. I have released 0.3.0 which has added support for ng5. If you run into any issues feel free to come and report them.

masiorama commented 6 years ago

Thank you very much! I'll test it by the end of next week and will give you a feedback.

masiorama commented 6 years ago

Hello there, I tested just the token drop upon authentication and it works with angular 5.

I couln't test any further because as far as I can understand from your code your API uses the host as the base url even to reach the data endpoints. In my specific case I am forced to authenticate to, let's say, an auth server (ie, auth.server.com/oauth) and to grab the data after authentication from a different server (ie, data.server.com/v1).

I know this is a total different matter, but I just need a brief clarification in order to understand if there is a way to user your lib in this scenario. Thanks in advance!

0xMatt commented 6 years ago

@masiorama, actually, due to a bug it seems this can somewhat be done by default. If you create a wrapper for your auth.server.com host, and extend that and simply override the host, they will access the same token data via fetchToken(). I have not tested this yet, but in theory it should work so I would give that a shot. However, don't rely on this approach as this functionality will be removed in the future. I will provide a default storage prefix(along with allowing developers to choose where the auth token is stored). If you want to discusss a better approach for an actual implementation supporting this. Please open another ticket and we'll mark it as a feature request.

masiorama commented 6 years ago

I don't understand what do you mean whan you say "this functionality will be removed". Thanks, I'll open another issue! #15

0xMatt commented 6 years ago

Right now, the storage_prefix configuration is optional. So if you have multiple api wrappers setup and do not set a default value, they will access the same local storage data which can be considered a bug. To help developers that use this library have a less troublesome time, I'm going to make it required.

You can still retain this shared functionality by giving both clients the same storage_prefix.

masiorama commented 6 years ago

Understood, thank you very much.