Wow, I had something to do… and was thinking that the external .js file was not secure, and I needed to come back here and make mention of that. Look at all of these replies! 
Good job.
1 Like
Errr ... actually, in my mind, that is in fact exactly the issue and, as you painstakingly point out, the only issue.
But you CAN do that, if you use a proxy, per my previous post, which you hadn't seen before writing the above -- and which I sincerely hope helps. That is to say, rather than continuing to, "beat you down with what you cannot or should not do", I figured it was high time I delivered a solution so you CAN do it and do so securely. 
Anyone you give access to your web app can steal your access token very easily and do with it whatever they want. I already said (twice) that if you are the only person who will ever have access to your web app, then none of this really matters -- unless someone gains access to your web browser cache or several other security paranoid ideas that come to mind.
Oh and, knowing what I do of the NSA and assuming you're using https/ssl to access you web app, then I suspect they wouldn't even bother trying to sniff your packets. They would just bust down your door and take your computer! 
You know, when all that NSA stuff got leaked, there was a catalog of custom-made "spy tools" that NSA agents could internally "purchase" and deploy. There were accompanying datasheets for a lot of them, even!
One thing in particular I thought was interesting was this little board hidden inside the ferrite bead that goes on a VGA monitor cable. This thing was completely 100% passive, requiring no battery or outside power. Basically, it had a tiny antenna wound around inside that could pickup the EMF coming from the red VGA signal wire. The whole was designed to be powered by a high frequency radar beam hitting it; another pair of antennas would take this RF energy, use it to power the circuit and then somehow modulate the reflected radar beam with data from the red VGA signal.
So a couple of guys could sit a block away in a van (with a fiberglass panel replacing the metal door) that contained a high power radar setup. From this, they could see everything you did on your computer. Because the bug was passive, you couldn't even sweep for it!
This isn't even close to current technology, either; it's at least 10 years old. Just imagine what they've got now!
The government spying on citizens isn't new. This has been going on since humans became agrarian and started vying for land. If they want to access your information, a couple of relays isn't going to stop them. What if they put spyware on your computer, so that when you reconnected to the internet everything you did in the interim was uploaded? What if they sit outside with a radar?
I hate to be Debby Downer, but the NSA has been monitoring phone calls and internet traffic since at least the 80's (Project Echelon). The only way to avoid being "speed on" is to go live in a cave somewhere, and even then, if they really want to find you, they will (just ask Oosama).
The advice @gruvin and others are trying to give you isn't designed to prevent the NSA from accessing your system, it's to prevent some 14 year old kid on 4Chan from screwing with your Core (or internet, phone and cable access since that's what you'll be using it for) once he "Views Source" and gets your access token.
By the way, how do you plan on disconnecting/connecting your Phone, Cable and WiFi? You're not planning on running your coaxial cable line through a relay, are you?
Spark cores?
2 Likes
And after some experimenting, here is an even further minimalized version of the proxy solution, but this time it also handles event feeds …
FILE: (see previous post (-5 posts) in this thread for full context)
index.php
EDIT: See later post, for later and better version, which fixes the problem state below and several more.
There’s one small catch with this unfortunately, for which there appears to be no work-around. When you sign up to view events via the proxy, the few few lines will not be flushed through to you until there have been a couple more. Thereafter, oddly, single events come through pretty much instantly. This appears to be a peculiarity with CURL itself.
It works just as described in my previous post, only now you can also …
curl http://your.domain/proxy/v1/devices/<core-id>/events
Learned some, knew some. for many years I repaired monitors and I know the part you describe @timb
My stopping the NSA is nothing new. A person can just pull the plug on technology and still can not stop the spying. They don’t mine for data or listen in using vans anymore as it takes to many resources.
No, no relay on the cable but, those are used in conjunction with Opto isolation and transistors for phone, ethernet and VOIP. The cable is handled by a FCC certified high frequency switch.
My core won’t be on the web. And yes, I do agree that using a php proxy would be much more secure for people who want to check the moisture on their plants or temperature at their vacation house but, you all have to think old school. The core is on the same side of my local lan, protected by a router/switch. I am not making nor will others make HTML / CURL / jquery POSTS to the internet. They are going to make them from the web to inside their own network. Not the other way around.
So you see, like I said, the issue is not that I can’t make a post request via a browser secure without a php proxy, the real issue is that anyone who makes any kind of http Request is exposing their access token number not only to local gov. thugs working for (not necessarily employed by) official law enforcement but, to anyone on the web; virtually.
Running HTML, Curl, jquery and even broadcasting a spark core access token on a locally protected network is where I am at.
Open Port - Insert Mouth. Port access —> AES Authentication --> Password Protected HTML (easily modified) User interface running on the core Tiny Webserver controlling all Core Pins should work.
And as far as how to stop the NSA unless you live in a cave; not so sure that deserves any merit as that’s kind of extreme poo-poo throw in the towel talk.
One Click from a remote takes a house completely off the Grid; no wires to outside, no spying possible but, there’s more. I hold a patent pending on the technology. Its called, “Telecommunication Subscriber’s Privacy and Disconnect Device” U.S. Patent Pending, Aug. 16, 2013.
The installation of smart electrical meters is a final blow to privacy but, we already figured out how to stop the spying here. By injecting high voltage - high frequency oscillation that sounds like a spark plug from an old 1965 Chevy six cylinder truck with sold core spark plug wires going a million miles an hour. We tested and it works. Can’t spy if you can’t filter it from the neutral & ground wires.
Sure, its not high tech like how the NSA has been doing it since the 70’s & 80’s but, the 5% of people who are my target audience want it simple and “OFF THE WEB”. HTML is simple. Open HTML Page. Shutdown NSA - Now what’s wrong with that ?
Added Note: I’m only using the Core API for testing prior to going local only but, I will pass on to folks the need to use a proxy if they choose to use the Spark Core Cloud. - as they will need it then for sure.
If the Core disables your WiFi, how exactly do you plan on turning things back on? 
As for no spying, well… When you talk the sound waves can cause tiny reverberations in the glass of your windows, a simple laser can overcome that. What bout passive bugs; how do you know every TV set manufactured since 2001 doesn't contain one?
Then how are you going to control it? Are you waiting for the local cloud?
Your router/switch isn't any protection at all, sadly. What type of hardware firewall are you using?
Here’s my “final” version of my secure proxy solution, which fixes the problems mentioned above and some more as well. This time I’ve done pretty extensive testing, so I’m fairly sure this proxy will cover most if not all Spark API uses.
WARNING: For reasons many hours of research has been unable to uncover, whilst the solution presented here is technically sound in principal, it seems there are numerous bugs in both the design and implementation of curl and Apache, which sadly make this approach highly unreliable. By all means give it a go on your own hosts and let me know if you have better success. Just be prepared for it to work like a charm for an hour, then stop for half an hour then go back to working, all with no changes on your part.
So, this is a PHP script, which acts as a go-between secure proxy server, so that your Sparkcore access_token is never sent to any web browser, where it can be “stollen” or whatever.
HOWTO
Create a folder on your web server named /proxy and install the following two files …
FILE 1:
.htaccess (no changes)
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* /proxy/index.php [L]
FILE 2:
index.php (look at pr
<?php
/*
* Original Author - Rob Thomson <rob@marotori.com>
* Original Source: https://code.google.com/p/php-proxy/
* Adapted and simplified for spark.io Cloud API use by Gruvin <gruvin@gmail.com>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
*/
/**** !!! IMPORTANT !!!
INSERT YOUR FAVOURITE PHP LOGIN ACCESS SYSTEM HERE
if (!$_SESSION['logged_in']) die("Access denied!");
*/
// HERE GOES YOUR secret Spark access token. This will never be sent to the browser
$spark_access_token = "YOUR ACCESS TOKEN HERE";
set_time_limit(0); // curl should time out 10 seconds before this (for event streams)
session_start();
ob_start();
/* config settings */
$base = "https://api.spark.io";
$url = $base . str_replace("/proxy", "", $_SERVER['REQUEST_URI']);
if($_SERVER['HTTPS'] == 'on'){
$mydomain = 'https://'.$_SERVER['HTTP_HOST'];
} else {
$mydomain = 'http://'.$_SERVER['HTTP_HOST'];
}
// Open the cURL session
$ch = curl_init();
curl_setopt ($ch, CURLOPT_URL, $url);
curl_setopt ($ch, CURLOPT_HEADER, 1);
if($_SERVER['REQUEST_METHOD'] == 'POST') {
$postinfo = "";
foreach($_POST as $key => $value) {
$postinfo .= $key.'='.urlencode($value).'&';
}
rtrim($postinfo,'&');
curl_setopt ($ch, CURLOPT_POST, 1);
curl_setopt ($ch, CURLOPT_POSTFIELDS, $postinfo);
}
$headers = array();
$reqHeaders = apache_request_headers();
foreach ($reqHeaders as $hdr => $val)
if ($hdr != "User-Agent") $headers[] = "$hdr: $val";
if ($reqHeaders['Accept'] == "text/event-stream")
{
$headers[] = "Connection: Keep-Alive";
$headers[] = "Keep-Alive: 300";
}
$headers[] = "Authorization: Bearer " . $spark_access_token;
curl_setopt($ch, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_1_0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 0);
curl_setopt($ch, CURLOPT_HEADER, 1);
curl_setopt($ch, CURLOPT_FORBID_REUSE, 1);
curl_setopt($ch, CURLOPT_HEADERFUNCTION, "read_header");
curl_setopt($ch, CURLOPT_WRITEFUNCTION, "read_body");
curl_setopt($ch, CURLOPT_TIMEOUT, 120); // standard two minute network timeout to better accomdate event streams
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 1);
curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);
//Send the request and store the result in an array
$response = curl_exec ($ch);
// Check that a connection was made
if (curl_error($ch)){
// If it wasn't...
// just be silent about it
// print curl_error($curlSession);
}
curl_close ($ch);
exit(0);
function read_header($ch, $head)
{
$len = strlen($head);
$head = str_replace($base, $mydomain, $head); //header rewrite if needed
if(!preg_match("/^Transfer-Encoding/", $head)) // skip transfer-encoding header (shoulnd't be present anyway)
header(trim($head));
ob_flush();
return $len;
}
function read_body($ch, $data)
{
static $bodyFrame = false;
$len = strlen($data);
if ($bodyFrame) echo $data;
if ($data == "\r\n") $bodyFrame = true; // don't output until after last header
ob_flush();
return $len;
}
?>
Now in your web app jQuery ajax calls, replace https://api.spark.io with http://your.domain/proxy (or https, if you have and are using it.)
Test using curl, just as normal, only now by going through your secure proxy. For example, …
curl http://your.domain/proxy/v1/devices/<device_id>/<function_name> -d "args=go!"
Note the absence of any access token. It is now handled by your secured server.
How does it work?
The .htaccess files makes it so any request to http://your.domain/proxy/xyz/abc is always sent to proxy/index.php for processing. The proxy implementation in index.php takes whatever it is sent, strips the /proxy part out of the URI and forwards (almost) everything else on to api.spark.io, verbatim – including the remainder of the URI (xyz/abc in this example.)
Critically, index.php inserts an HTTP header, "Authorization: Bearer ", to authenticate the request made to api.aprk.io.
Anything returned by api.aprk.io is forwarded back to the calling agent (browser jQuery ajax call in this case) again, verbatim.
So your token is never sent to anyone except api.spark.io, over an SSL link.
In other words, so long as you only allow web requests that are already authenticated with your server – through your favourite means (see the code comments near the top of index.php) then only those authenticated browser users can access your core, without anything ever sending your token to anyone except spark.io.
Obviously, your server should not allow access to the source code of proxy/index.php. But that should be standard case on the vast majority of modern hosts.
You could go an extra step and have index.php include a file from above public_Html, say …
include dirname(__FILE__) . "../../secret_token.inc"
Note that some servers used to have a little known mechanism for requesting index.phps, which would server up a nicely color formatted version of your php source code! Check, but I’d be surprised if that were the case on any modern, sensible server nowadays.
EDITED a zillion times, while trying to overcome intermittent, weird faults. I believe this code is just fine. However, my server in CA/USA seems to have issues with the network path to api.spark.io – sometimes, which has made debugging very frustrating. As of this typing, events, variable request and function posts have all been working flawlessly for the last half hour or so. So I’m calling it a wrap (and a day.).
1 Like
Yes, routers are not secure no connection to the GRID is 100% secure unless they are physically disconnected from GRID - this is what my Patent Pending device does.
Remote Control is facilitated by using a 1 to 4 buttons of a Adaftruit 315 Mhz Remote Control. Phone wires, VOIP, WAN Connection & Cable are all disconnected; and
This is only done when a person “absolutely requires” Off Grid Absolute Privacy. If they are being monitored locally via parabolic mics or via reverberations from glass, well, nothing will stop that unless the person moves to a much needed cave dwelling
Not trying to secure a person from the GRID’s Invasive actions by such rouge outfits like the NSA. Just for times when a person does not want to be recorded.
Look, this is a nice project for me and if I help keep people from being F’ over by corrupt 3rd party corporations (which is what is really going on) I will have helped even a little bit.
I only want 5% of the people in America to be protected. The other 95% who are the problem in American can jump off a cliff as they have allowed America to become a debt ridden 3rd world nation; rights being taken away to make us safe from terrorist.
And to be clear, I am not in this for the money. The patent is only sought to prevent another entity from trying to stop this technology being used by others. Such an action that will only cost these spy companies money; keeping people out of jail; and possibly stop retaliation against people who dare do things that go against this now socialist country.
My job is to make the most simplistic user interface that can be integrated in to a Joomla component for easy modification.
I say its safe; enough but, others can prove me wrong if they want.
Using only HTML (mostly residing on the Spark Core) and jquery post requests to the Spark API I can control all analog or digital pins and set their state, Read or Write. Credit goes out to Spark Team as I am using DigitalWrite string function from the Tinker App. I am also using Tiny Webserver and connecting to the core via an local IP address and core is connected to the Spark API.
I have already tested using HTML & Pure PHP to accomplish the same control of my Spark Core.
Any and all comments; criticism and hacking are surely welcome as it only helps me fix issues I have not consider. We have already discussed the lack of security by making post requests to the Spark API which can not be prevented; it is what it is. However, I am only demonstrating that a hobbyist does not have to become a Android or iOS programmer to control their Spark Core.
The IDE built in there is pretty genius. Log into the spark core to program the spark core. How meta!
Did you run into any issues with memory consumption serving up the web page?
No memory difficulties so far and its a work in progress and will be for a while since I have no formal code training.
@Dave was nice enough to provide code for Tiny Webserver in this post: https://community.spark.io/t/tiny-webserver-code/3297
1 Like
Looks good to me.
Clearly, only the intended user/owner of your device ever gets to see any webpage containing any ajax requests to external servers of any kind. Thus, all my warnings about broadcasting your access_token are out of context and do not apply at all. (Pretty sure I said that already, once or twice, at least.)
So now, the only issue I see is that, once you turn your cable modem off, you lose control of your sparkcore, because you are still relying on api.spark.com to get those commands through. On the other hand, you already have all the pieces needed to communicate directly with your sparkcore, thus not requiring any link to api.spark.com (or spydrop.com) at all.
What I mean is, instead of only serving up web pages from your spark', as you are at present, have that "tiny web server" also recognise special URIs to command your 'core directly, without any outside involvement. No tinker functions or variables -- no Spark API what-so-ever. No outbound connection to spydrop.com or anywhere else outside you local LAN.
For example, instead of jQuery sending requests to spydrop.com (and then onto api.spark.com, if I understood that correctly) have your sparkcore-served jQuery HTML code send GET requests something like, "http://100.x.x.x/?p1=0". Then have the code on your sparkcore (the tiny web server part) recognise and interpret that URI (?p1=0) to directly turn port 1 (p1) off (0). See? No external servers required. (Yes, you lose or the Spark provided API functionality. But your project does not require any of that -- and you would still retain remote programming from the Web IDE (and all the API functions) so long as your cable modem is up, of course.)
In other words, implement the first TODO in the tiny web server example code ...
void serveWebpage() {
//TODO: read in the request to see what page they want:
... where, "what page they want" can also be, "what LED/relay they want to control".
Hope that made enough sense.
Finally, I just realised that we're now way off the OP's original topic. (Forgot that was not actually you!) So feel free to open a new topic and link to it here, if you like. A subject something like, "Direct local control of sparkcore" may make sense.
1 Like
Thank You very much for your post. This helps me a lot as I go off on a tangent that lasts for weeks only to relize later its a deadend and someone said there is a better way. I agree with you that using speacial URIs to control the Spark Core pins is exactly what I need to to be off the grid. I was able send these URI reguests to an Arduino UNO R3 by setting a function that passed paramters directly to the Arduino MCU but, that’s not possible with the Spark Core (Or at least I don’t know how).
I will do some more research and testing to see what I can figure out. I will also do as you suggested, create a new topic for Direct Local Control of Spark and strap on my vest 
Thanks Again for your great and very helpful comments.
Bobby
2 Likes
I took your advice and I am now storing my Token Core Number/ Variable on the Core Itself - not on the web.
Correct me if I am wrong but, this methoud will be much safer than using a *.js file that would have my token number and set a varialbe for it ?.
All my html / jquery code now resides on the core also and I can control DigitalWrite forl D0, D1, D2, & D3. ON/OFF (HIGH/LOW)
Now all I have to fiqure out is how to connect to the API cloud using Jquery (maybe have to use Curl).
Thanks for your comments that pushed me to find a better solution.
Bobby
1 Like
@spydrop … for your use case, what you say above sounds perfect.
In terms of how to access the cloud API, you simply do that in the normal way – with the access token directly in the jQuery/HTML source code. There are no issues with this, in your use case. You can safely forget almost all previous comments on this topic (above) – because of your specific use case.
To explain though, only the web browser internal to the home in question, owned and operated by the owner of your device, will (in theory) ever have access to the jQuery webpages, as served by your 'core. Therefore, there is no harm in providing the access token to that browser in the standard way. Yes, the access token will show up in the source code of that browser. But in your case, only the owner of the device you are designing will have access to that source code in the first place. So there is no security leak.
The only reasonable exception to this might be if the owner was accessing the HTML being served by their device over a non-secured WiFi link – like WEP security or no encryption at all. In that case, someone within WiFi radio range and with the time and motivation to do so, could sniff the TCP packets running between the core and browser and potentially discover the core’s access token. This is turn, is only because you do not have the opportunity to establish an SSL link to the sparkcore’s, “tiny web server”. (The sparkcore can make secured outbound SSL connections, but not accept inbound SSL, since that requires much more resource and configuration.)
However, when the jQuery code, along with the cloud access token executes in the web browser, then the web browser (not the 'core) will make a secure, SSL encrypted link to the cloud API. So, WiFi or other local network packet sniffing aside, your access token never leaves the browser or indeed the property where your device resides, without being encrypted.
As you now know, direct control of your core without using the cloud API also does not involve the access token. You are relying solely on only a locally connected web browser being able to download HTML content directly from your core, in the first place (which is fine.) In my view then, this is sufficient and practical security. (IE. Anyone willing and able to circumvent these measures will also be willing to extract whatever information they desire through other, much more nasty means, far beyond the scope of this thread, I should hope! )
So in summary, for you specific use-case – just put your access token in the jQuery code served by your core – in the exact way prescribed by the standard API documentation – and that will be fine.
The issue I originally raised was for the OP of this thread, whose use-case is probably not the same as yours. Indeed, my warnings assumed that the web page containing jQuery code could be accessed by potentially anyone, without any purposeful, “hacking”. This is not the case for your intended design, as we now understand it.
Hope that helps.
1 Like