Yep! @mdma is working on it!
EDIT: I don’t know exactly what’s happening (it seems like a regression), but in talking with Mat he didn’t seem to think it was too spooky. I know he has a lot on his plate right now, but he’ll let me know as soon as he’s got a fix for it!
The issue with HTTP SoftAP setup is fixed and will be part of 0.4.4 to be released this week.
@nexxy, @mdma, can you please summarize what is the final functionality we can expect ? Specifically:
will there be a web page in the Photon firmware, allowing for easy WiFi setup using just a browser (like in @mebrunet’s firmware) ?
will there be a possibility to have both WiFi client and AP on the Photon ?
will the web browser app (served from external server) based on softap-setup-js work with Photon Soft-Ap (the CORS problem mentioned in the thread) ?
how about the https://github.com/spark/firmware/issues/396 ?
Thanks
Hey! Surely. Here is what I know about our current plans for SoftAP Setup — which may be subject to change, especially given feedback (such as your own)!
Sorry I don’t have all of the answers, but I hope this helps! I’m happy to answer any other questions you have, and I’m sure @mdma will pop in when he comes up for air.
I’ve got a simple HTTP setup page working. The final step is to serve it from the Photon. My original plan was to minify it to a single line string and serve it with WICED_STATIC_URL_CONTENT. (The same way you served the response to /hello) It’s a bit of a hack I know, but I just need something working ASAP.
However, when I take that approach the request seems to hang unfinished if that string get’s too long. (i.e. I can serve simple html/javascript page, but by the time I’ve emebbed all the RSA encryption stuff it’s just too long). I could keep hacking and spread the page over several WICED_STATIC_URL_CONTENT endpoints… but that starts to get really ugly. I would much prefer to use WICED_RESOURCE_URL_CONTENT to serve static pages, as Broadcom does in their WICED SDK example apps. But my C++ is rusty and their documentation about how to do that is almost non-existent. So I was wondering if I could get some of your help.
I’ll be sure to get the solution online and documented when finished.
Sounds cool! Can you try the latest develop code - it contains a fix that increases the stack size of the HTTP service which can stop it crashing.
I’m happy to help - please submit a PR and we can work on this together. 
Okay thanks, I’ll give that a shot this afternoon. What’s a PR?
A PR (Pull Request) is a way to submit code via github - we can both work on the same code and have a discussion.
This might help.
Haha kk, thought you were referring to something internal to Particle. Thanks.
Hi Everyone,
I’ve finally managed to prototype a solution for this. It’s still ugly and buggy, but working (for me - Chrome v44). The Photon serves a simple HTML/JS page and walks the user through the connection process. Get code and further instructions here.
Cheers!
Screenshot of the latest version. It’s working pretty well now! I’d hand this out to clients as beta.
@mdma & @nexxy - I noticed that the develop branch of the firmware adds Access-Control-Allow-Origin: * headers. That’s great! But the Photon still doesn’t seem to accept OPTIONS requests, so while I can GET anything cross origin, I still can’t POST. Are you guys working on that? It would be great to host this page off-device!
Looking great!
That is absolutely awesome! Great work!
@mdma will be the one to fix OPTIONS requests, so I will defer to him on that!
Thanks!
Another issue I’m facing is compatibility with the develop branch. Right now I can host this by tweaking photon_043. My basic strategy is to add a bunch of new WICED_STATIC_URL_CONTENT endpoints in softap_ip.c , change the size of the page array in softap.cpp accordingly, then compress all my web pages into strings (but nothing too long… haha or the request hangs).
However, I can’t seem to add new WICED_STATIC_URL_CONTENT endpoints in the same way on the develop branch. I’ve diffed those files and can’t see why it won’t work, any hints? @mdma ?
Nothing comes to mind. The only change to HTTP for a long time was the addition of the XHR header and increasing the stack size for the HTTP server.
Regarding HTTP OPTIONS, I’m not sure that’s supported by the wiced HTTP server. Can someone provide more details about what’s needed since we might have to code this ourselves.
Okay I’ll try v 0.4.4 and see if I have more luck.
RE. OPTIONS: Come to think of it, I remember going over WICED documentation a few weeks ago… I’m pretty sure it specifically states it can’t handle OPTIONS 
. Rather than coding that from scratch, why don’t you also get accept a GET and we can pass the ssid, pwd…etc. in the query params? Kind of hack, but not terrible, the password is encrypted, and it’s AJAX so the 330 chars required won’t actually show in the url…
Could you make a PR to our repo with your current changes, against develop, and we can discuss firmware development there? Cheers! 
First off, from someone who also requires this functionality, I appreciate the hard work everyone has put in on this!
Preflight/Options shouldn’t be required if POSTing one of these content types:
although I’m just now getting started on this piece and I’m not sure what content-type the Photon is expecting. if it’s application/json I don’t believe there is a way around the preflight.
It seems like there are a couple of options(no pun intended):