Open dmcquillan314 opened 8 years ago
So we put a specific redirect so that you can see the immediate success / failure of the authentication, and ask you to remove in production because the inappbrowser then utilizes the auth.ionic.io redirect to signal a authentication completion on device.
Effectively, you have configured the authentication correctly and it would work as intended on device (unless maybe you've not installed the inappbrowser plugin).
What errors did you encounter in the other examples? All examples should work out of the box.
So would I be correct in assuming that the custom Auth module would not function in a browser since that url is only available from within the container? That would essentially prevent us from using this app on both desktop and mobile devices.
The issues that I encountered for the node example were by following these steps:
node express/server.js
$URL=node genurl.js b7d11804
url -L -X GET "$URL"
Which results in:
{"meta": {"status": 400, "version": "2.0.0-beta.0", "request_id": "8c102e91-7c50-4dae-9f2f-4380c0f7ba23"}, "error": {"message": "Token not valid: could not decode JWT", "type": "BadRequest", "link": null}}
I'm using node v5.5.0
The authentication itself works regardless of context, but the utilization of the token that is received is context dependent. In the context of the platform-web-client, the token is expected in localstorage, which should be available everywhere. Having said that, the platform client sets this by capturing the redirect to auth.ionic.io using the inappbrowser plugin. If you're running it in a pure browser implementation you would need to set this manually.
We already have plans to allow you to call this directly in the case that you don't actually have a web form to show to your users, so when that is implemented you would be able to bypass the need for inappbrowser entirely.
As for the node issue, we are unable to replicate. We tested with node v5.10.1, so it's possible there is an issue with the node version you've tested with. Do you have an example token that this is failing on?
Do you have a timeline on when the in app browser requirement will be removed?
As for the node issue here's a sample token that I'm sending:
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoidXNlci1mcm9tLWV4cHJlc3MiLCJpYXQiOjE0NjE4NjgxMjV9.YzYDaDDsU1bxOd_Mv1b0f8BGJNg6pTDZLwjAhyOgkBc
I don't have a timeline for you at the moment.
Looking back on our logs, it appears your request gave a 400 error, but the token itself was valid. I'm wondering if either we had a blip on our end, or if you've got an outdated version of these examples?
I'm attempting to write up a simple proof of concept rest api using the custom auth examples but I've been unable to get it working. Currently, I'm working with the flask server side implementation since I can't get the other two examples working (node fails due to a decryption error in the ionic api). When I'm using the default implementation in the repo with the redirect_uri param set to the https://api.ionic.io/auth/integrations/custom/success path it works fine but yet in the notes it says that it should be removed before going to production. Therefore, in order to do my full test I tried removing this parameter but I get redirected to:
http://auth.ionic.io/login?app_id=b7d11804&token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJqdGkiOiI5ZmY3MjQzMi04OTUzLTQzZTEtYTAxMy1lNDRlODVhYzI2ODQifQ.FiK5k_bgWe83aUOg1IuU3-ybBtWzlrDp0HcWm1CEEDs
instead of:
http://api.ionic.io/login?app_id=b7d11804&token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJqdGkiOiI5ZmY3MjQzMi04OTUzLTQzZTEtYTAxMy1lNDRlODVhYzI2ODQifQ.FiK5k_bgWe83aUOg1IuU3-ybBtWzlrDp0HcWm1CEEDs
Maybe I'm just not understanding something about how the custom authentication is supposed to function?