Thanks for your PM @indraastra! (I’m replying here in case anyone else can benefit from the discussion).
I’ll keep your code private, for your peace of mind. I really appreciate it thanks.
So yes, with your OAuth set to redirect to httpbin, there seemed to be no problems, and my post was successful. I substituted my information back into your code and was greeted with the usual CORS related error:
(I’ve blacked out the redirect_uri as my company hasn’t fully gone public yet)
So, I obviously need to be redirecting to my own setup page. Will this issue go away if I’m hosting both account creation and setup on the same server? I’ll try it now.
Unfortunately, the redirecter is api.particle.io, so I’m not sure if your idea will work. I think you’ll have to allow cross-origin requests on myCompany.io/setup (or whatever the redirect target is) for this to work out, but @jeiden would know better.
Thanks @indraastra, yes my lack of knowledge on CORS means I’ve had a bit of a try everything approach. But it looks like you’re correct in your understanding. My idea didn’t work.
I’ll do some research on allowing cross origin requests. I’m a bit surprised no one has posted about the same problem yet but perhaps they figured it out on their own. Thanks again for your help!
However, since my public facing webserver is NGINX, I’ll need to add the code from the following website to the nginx.conf file I believe: http://enable-cors.org/server_nginx.html
Before I do this, @jeiden or @zachary could you let me know I haven’t gone completely off track?
@G65434_2 thanks for helping pave the way for others here. I need to discuss with some other engineers here, but I believe that you’ll need to use localhost tunneling + separate OAuth clients for each environment/domain to avoid this CORS issue – one for your local development and another for your production domain.
I’m pretty sure that the issue lies in the fact that you are running a development server on localhost but are redirecting to an http, public-facing URL. You need to “tunnel” your local development environment to be exposed as a public URL.
Once you have tunneled your local development environment to be served on a public URL, your development server will be running on a URL like http://92832de0.ngrok.io.
Then, you can use this URL as the base for your redirect_uri when creating an OAuth client for development purposes. For instance, if the first step after customer creation was /setup, you would set the redirect_uri to http://92832de0.ngrok.io.
Does this make sense? You should get in the habit of creating separate OAuth clients for each domain that your app would be running on, and swap out those clients for each environment.
No problem at all! Others will undoubtedly have the same question.
If you’re serving static file content, then yes, you’ll add that to the webserver (apache, nginx, etc.) config.
If you’re responding to the request dynamically (with php, node, ruby, python, C#, java, etc.) then you could either set the header in the webserver config (as above) or in your application code. Just look in your web code framework’s documentation for how to set a header on the response, which often (kind of a “gotcha”) must be done before you start serving the actual HTML content of the page.
@G65434_2 I think the problem stems from using an AJAX request for OAuth implicit flow. Because the response does a redirect, you really should be using a normal HTML form. Otherwise the AJAX request is the one being redirected, not the page, which causes the CORS error you are seeing.
How would I go about writing a form for this? (Sorry there’s a few different ideas going around here and I’m not a web expert!). Would it be something along the lines of this??
That worked! Thanks @bryce, I spent a crazy amount of time trying to get that to work with ajax.
I have noticed that my client-id now shows up in plain text when viewing the page souce, is this ok? Although I suppose it was trivial to find it before from the developers tool by looking at the JS source anyway…
client id being exposed is fine, client secret is the one you want to protect. Implicit flow exists to not expose the secret without the need for a server.
can you please summarize what is your current progress with " Example Web Setup App " ?
What actually works, do you have any code to share ?
As I lately received info from Particle guys, that they are not going to make “organizations friendly” JS SDK for at least 3-4 months, I’m wondering what really can be done with JS using HTTP API.
I’m planning the same as you - create customer + setup WiFi + claim
Sure thing, I’m currently away from my main computer but I’ll post some code as soon as I’m able.
So what I’ve currently been able to do is this:
-Create a login using the JS library
-Create a ‘register new user’ button below the login one for creating new user accounts
-Subscribe to data pushed from the Particle devices in a dashboard type setup
-Send WiFi credentials to the device using the SoftAP library
What I’m yet to do is add a couple of lines of code in my SoftAP JS to ‘claim’ the device when it’s WiFi is setup. This shouldn’t take too long however.
My company is currently going through quite an expensive freedom to operate and IP viability investigation so I can’t quite release my website yet but I will as soon as I can. In the mean time I will post some code fragments to help others along. (Once I get back to my computer).
thanks, I do have the whole web ready (ready for the device I’m building, with functions and variables) , including SoftAP wifi setting. It allows login with particle credentials.
What I’m still missing is:
eating OAuth credtials (for the app)
creating particle users with it
claiming device
I have been following this conversation and other posts on this topic and I still have some issues in successfully claiming a Photon (Simple Authentication). Following the example of @G65434_2 and the tutorial, I have succeeded in:
Creating a OAuth client ID.
Create a customer + getting customer access token.
According to JavaScript console, the claim code is successfully sent to the Photon. From what I understood reading the docs, when the Photon gets the WiFi credentials and connects to the Internet, it sents back the claim code to the Particle Cloud to finish the claiming process, but on my Particle Dashboard I cannot see any claimed device and not even a customer created.
I have read the docs, but I cannot figure out what I am doing wrong. @kefir135, @bryce, @jeiden any ideas of what might be happening?
@lia Your process sounds correct. I would start by pinging @mebrunet, the maintainer of the softap-setup-page repo to see if he has ideas. Note that the officially supported way to do this is using our mobile SDKs. This is a community-contributed tool