Example Web Setup App (Simple Authentication)

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.

1 Like

It looks like CORS issues are to be expected unless the redirecter and the redirectee share a domain:

https://code.google.com/p/chromium/issues/detail?id=154967

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!

So from some quick research it seems we can add something to the htaccess file on the host server.

Header set Access-Control-Allow-Origin: http://myCompany.io

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? :smile:

1 Like

@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.

The one I’ve used before is ngrok: https://ngrok.com/.

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.

3 Likes

I’m thinking that when you serve mycompany.io/setup that you’ll have to set

Access-Control-Allow-Origin: api.particle.io

or, to be more permissive, change api.particle.io to *.

Thanks @zachary, please forgive my ignorance but would this be added to either the apache or nginx config file depending on the setup?

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.

1 Like

Great thanks @zachary! I’ll have a go at that tomorrow and post my results then :slight_smile:
(And yes I am just serving static content for the time being).

@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.

2 Likes

Thanks @bryce

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??

<form action="https://api.particle.io/v1/orgs/myCompany/customers/email=email&password=password&response_type=token&client_id=myappID" method="post">
  email: <input type="text" name="useremail"><br>
  password: <input type="text" name="userpassword"><br>
  <input type="submit" value="Submit">
</form>

Use email and password for the names, and hidden inputs for the other arguments, like below:

<form action="https://api.particle.io/v1/orgs/myCompany/customers" method="post">
  <input type="hidden" name="response_type" value="token" />
  <input type="hidden" name="client_id" value="myappID" />
  email: <input type="text" name="email" /><br>
  password: <input type="password" name="password" /><br>
  <input type="submit" value="Submit">
</form>
2 Likes

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.

2 Likes

Hi,

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

thanks !

Hi @kefir135

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).

Cheers,

1 Like

Hi @G65434_2

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

BR

Anyone following here, I’ve started a bit of a tutorial over here: Tutorial for a simple web app

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:

  1. Creating a OAuth client ID.
  2. Create a customer + getting customer access token.
  3. Create a claim code using: https://api.particle.io/v1/device_claims?access_token=access_token_of_customer_created_in_step_2.
  4. Send WiFi credentials using SoftAp (using the work from @mebrunet - https://github.com/mebrunet/softap-setup-page ), including the claim_code parameter generated in step 3 in the url ( http://mydomain.com/softap/?claim_code=claim_code_generated_in_step_3 ).

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?

Thanks

@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