@Bdub thanks! I got it running with Tera Term. It appears that when I plug the core into the USB and start TT when the cyan breathing starts, the serial connection is made without a problem.
A core with your code and that is not connected to a terminal, would it still be on hold? If it would, this would be a bit annoying during debugging, wouldn’t it?
Excellent ! Glad to see others benefiting from this forum but, Make sure to Thank both @BDub @bko as they the ones who helped me to help you 
Did I say that right ?
Keep us posted on your progress and share any projects you create.
Bobby
1 Like
Sometimes if you are not sending data to the Serial port too fast, you can open Tera Term without a problem in-between writes. But other times you need to pause the program to allow you to open Tera Term. If you need it, it’s not annoying. If you don’t need it, it could be annoying depending on your application. I wanna say Arduino solved this problem by resetting the ATMega328p via the DTR line every time the Serial Monitor was opened… thus avoiding conflicts with the port. That’s VERY annoying because your app will start to run, and then you reset it when open the serial monitor, then it runs again. There are similar ways to pause your Arduino from running until the Serial port is opened though. Every dev platform has it’s little quirks.
Let’s consider what would happen if you didn’t have to pause your program to open your serial terminal… you program your part, it resets and runs… it begins the serial stuff which loads the COM driver, this is the first point you could open the serial terminal… now your code is running and data is being transmitted to the computer… but your serial terminal is not open yet… come on SON, open that thing, you’re missing data! So the downside to having convenience is decreased effectiveness/performance/usability (call it what you will).
If you are debugging over serial, pausing probably makes more sense… so you can catch the first instance of something, or start looking at your debug information at a known point in time. If you are not debugging, but are just playing… lost numbers whizzing past might not matter much (like just seeing the output of your accelerometer).
Are there any examples in the docs or forums showing how to keep the token (and ID) secret?
I build a candy dispenser using my Spark Core that is triggered from a button on a public web page and everything is working fine. But if I view source - there are my ID and token for the world to see.
So I was wondering if people had specific recommendations for how to hide this info. My current webpage is incredible simple - button and send() function using ajax POST (tip of the hat to @gaudsend for sharing his code).
Does HTML support include files? Should I convert it to PHP so I can use a access.h file to hide the values? Would that even work? My HTML coding chops are very rusty so any help greatly appreciated.
Hi @longarc I started this topic a while back because there is no help in the Docs for this very important situation but, the community has been very helpful in pointing me in the right direction. see my video below where I am controlling spark core from HTML file using jquery Post request.
Credit: My Code is based from work by PDP11’s Pastebin http://pastebin.com/ZA22CGKn
@longarc If you are using jquery to make your $.Post request in your html page that is best; I believe. It can be done with PHP as well by using a PHP file include statement in your HTML file and setting permissions on the external PHP file in a sub-directory will conceal the access token. In addition, adding an isset() statement in the external php file containing the access token to validate the request as a valid request from same particular domain or that the request being made is a post request makes it virtually hacker proof.
If someone can help me with a simple syntax for appending a jquery variable to the end of my jquery Post request I have what you need @longarc
So @bko & @BDub & @Timb & other spark elite & Spark Team members your help would be very much appreciated in this quest to simplify the HTML / jquery control of the spark core and allow I, @longarc and other community members the ability to conceal our access token. Great Idea Right ? 
QUESTION: What is the proper syntax to append a jquery variable to the following jquery Post statement.
function phoneOFF()
{
$.post("https://api.spark.io/v1/devices/48ff6f065067555028091087/digitalwrite?access_token=**{insert jquery variable syntax here}**",
{
args:"D7,LOW"
});
}
// jquery exernal file:
$(document).ready(function(){
var $accessToken = '9876123947861293874612938746192873648976';
});
Test Files are here live to my core - Not protected for real time testing.
http://bartertronics.com/test/test.html
http://bartertronics.com/test/code.txt
http://bartertronics.com/test/includes/magic_token.js
VIDEO OF MY TESTING
I would say:
function phoneOFF()
{
$.post("https://api.spark.io/v1/devices/48ff6f065067555028091087/digitalwrite",
{
args:"D7,LOW",
access_token:"978612398476219387461293874691287346"
});
}
This part is inline JSON:
{
args:"D7,LOW",
access_token:"978612398476219387461293874691287346"
}
This is useful documentation:
https://api.jquery.com/jQuery.post/
And you can see a nice example with callback there:
$.post( "test.php", { name: "John", time: "2pm" })
.done(function( data ) {
alert( "Data Loaded: " + data );
});
@BDub Thanks & yes the inline works but, what I am trying to do is like an include statement from PHP.
I want to set the acess_token number to a jquery variable in an external magic_token.js file; include the file as Javascript/text file in the HTML file < -----Head -----> Seciton; and finally place the access_token variable in the jquery $.Post statment.
I can do it in PHP but, I can not figure out proper syntax for using jquery to append the access_token number in the jquery $.Post statement.
Help is appreciated and its all I need to finish for user interface so I can hook up my spark core to my MagicStop Controller; do a video; start my campaign to stop the Spies and finally take overt the world (LOL)
Ok here’s part of the problem:
Just add test/to your path in your HTML file.
<script type="text/javascript" src="/test/includes/magic_token.js"></script>
Actually I see you are running your HTML file from the TEST directory, so I’m not sure why it’s trying to load from the root of your website… but it is.
or maybe
<script type="text/javascript" src="./includes/magic_token.js"></script>
Then in your code you can use it like:
function phoneOFF()
{
$.post("https://api.spark.io/v1/devices/48ff6f065067555028091087/digitalwrite",
{
args:"D7,LOW",
access_token: $accessToken
});
}
and then CHANGE YOUR ACCESS TOKEN so NSA is not all up in your CORES 
Hmmm, assuming I understand your intention correctly; That won't actually achieve any hiding of the access_token. Anything the web-browser can read -- and has to be able to read your magic_token.js file -- can be read by anyone who has access to the main html document. It might prevent the token being so easily viewable with a simple, "View source". But any hacker worth her salt would quickly see that magic_token.js is where the token is hiding.
Currently, the only way I know of to make the access token not viewable to the public is to use a PHP script to proxy all access to your core. Your HTML page makes calls to that proxy only, which then passes on the calls to api.apark.io.
In the future, I believe Spark will be extending their oauth implementation to provide more options for client authentication. I'm not sure exactly what is planned or what schedule may relate, at this stage. This may one day include the ability to issue access_tokens that can only be used for specifically granted variables or functions. But event hat does not solve the problem of obscuring your own "master" token, for full control. For publicly accessible web-apps (web pages with jQuery http requests), you'll still need to use a proxy for that.
If your web server can do ssl/https (even with a self-signed certificate) and if you use traditional means to authenticate a user before they can open the page containing the jQuery 'core control code (along with the access token) then things will automatically be more secure. However, the access token will still be "in the clear" for that authenticated user and could conceivably be copy/pasted by a "friend" sitting at the computer while you go to get a coffee or whatever. So I would still be using a proxy PHP script, if it were me.
Also note that at present, all tokens expire after 90 days. So be prepared to have to generate a new token within three months. This can be automated however, using an API call. It's in the docs.
I believe there are plans afoot to make tokens much more flexible in the future, including idea to be able to issue "read only" tokens, to access variables, not functions and more.
2 Likes
Yes, once again you have saved me lots of time and frustration. I did spend 8 hours yesterday searching google & youtube but, did not find an answer. Now, the NSA will soon be out of my life (once I remember how to change that access_token)
The bad linking to the external js file was my oversight as I copied files to test folder before making my request for help today but, I forgot to update the .js link. Thanks for pointing it out, I would of been scratching my head about that for a while.
THANKS TO YOU its working.
I will work on jquery presentation for button width instead of using space char. then post finished code at github and link back here.
Thanks Again as I really do appreciate your help.
Bobby
_____HTML FILE------>
< HTML> < head>
< script src="http://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js" > < /script>
< script type="text/javascript" src="token.js" > < /script>
< /head >
< body >
< button type="button" onclick="D1on()">LED D1 ON< /button>
< script>
function D1on()
{
$.post("https://api.spark.io/v1/devices/Your_Core_Device_ID_Here/digitalwrite",
{
args:"D1,HIGH",
access_token: accessToken
});
}
< /script> < /body> < /html>
<— HTML FILE______________
External token.js file---->
$(document) .ready (function()
{
accessToken = "your_Core_Access_Token_Number_Here";
});
Will post complete code at Github and link back this topic page.
Yes, you are correct - if its on the web and not encrypted then a true hacker can see it.
A true hacker can hack a mySQL database as well.
Using issetI() in the external .js file will restrict any calls not from the domain where my html file resides and setting file permissions will keep access token secure from most bots, etc.
Final code will have the access token obtained from a mySQL database table where the access token will be encrypted.
A password protected (apache) form will be used to change the access_token manually in the mySQL database until such time it has been automated in some fashion.
ADDED NOTE:
My intentions initially are to be off the cloud all together and I only need the core to activate 4 to 8 relays on my Magic Stop Controller via transistors with opto isolation.
I don’t like the idea of sending the access token via Post requests at all but, it is what it is until such time there is a work around.
Hmm. OK. But I still don’t see how any of that will help your cause, sorry. In all examples you gave, anyone who can load the main HTML page can also view the token. If the jQuery script can read the token, then anyone can. It doesn’t take a “true hacker”. There’s no fancy skills involved at all.
Again, if you use a jQuery request directly to api.spark.io anywhere in any web page that someone’s browser can load up in the first place, then the token is in the clear. It does not matter how many hoops the scripts on that page have to jump through to obtain the token. If the token is available to a browser, then it is available to anyone with a browser, who can load the page in the first place. Simple as that.
Nor does it matter if the request is coming from the same domain or not. In fact, that’s not even relevant, since the browser requests are coming from random IP addresses. We are not talking about PHP scripts calling other PHP scripts. This is about external web browsers, making external requests. It’s already out in the wild.
If the main page with the jQuery http requests is available to any given browser – no matter how that browser is instructed to obtain the token for its own use – then anyone can see the token, with ease.
In your current test case, it’s as simple as typing this into the browser address bar …
http://url.of.main.page/token.js
There is nothing you can do in token.js to prevent anyone from loading it. It’s just a public HTML document. It is not a server side PHP script. Even if it were a PHP script that did security checks, it’s still going to send the token out in clear text, once those checks are satisfied.
So yeah. I don’t know how many other ways I can say it. If you send the token to a web browser – no matter how you do it – then the token is in the clear for anyone sitting in front of that web browser.
@gruvin is 100% correct. You cannot secure any data that makes it to the browser.
Ie. You don’t put the goods on somebody else’s computer and hope to keep it safe.
If you plan to have your app be completely in javascript, then plan on this security limitation.
The only secure way with the current spark features is to have all the data calls go through the server.
The next best thing is to at least not have it sitting in your source. Put a password protect on the page that will then query the server for the token. From that point forward it’s in the browser again and not secure, but at least you trust the person with the password.
On my site, if you’re not logged in, I force you to enter the token in a form.
Hopefully the spark team addresses this with read only tokens at least. I can live with somebody reading the temperature on my device. I just don’t need them having the keys my spark kingdom.
So what your saying is the core API is not secure ? Simply because a POST request is being made by a browser is somehow less secure than using an Android Java script ? how is this true?
The lack of security is not on the server side or displayed in the browser. Paypal uses a lot of jquery to transact $ Millions of dollars each day; are you saying they got it wrong ?
Using MD5 hash & passwords with encrypted passwords in a mySQL database that never displays the actual access token in the browser of in a page display is not the problem.
The problem is using POST request to the Core’s API and passing the Access Token “unencoded”.
Many examples on this site of simply placing the access token in a html page that is not secure.
Its all moot to me as I have no intentions of using my core over the web.
I am only using it to show people how to stop the NSA !
No. That is not what I am saying. The Spark server accepts requests only via https/ssl connection. So it is secure.
HOWEVER ... if you create a web page and use jQuery within that webpage to send requests to the Spark api server, then anyone and everyone who can download that web page to their web browser, gets a clear text copy of your access token.
That token is securely sent to the spark api server when jQuery sends the request. But the token is clearly visible within the web browser source code -- no matter what lengths you go to to get it there.
PayPal does NOT do any such thing. All security is handled server side and all data is transported over SSL. No passwords or tokens are ever transported to the browser (except session identifiers, valid only for that session) encrypted or otherwise -- ever. Hashes or even clear text, albeit SSL transported passwords are routinely sent from the browser to the server, but NEVER the other way around.
Conversely, your web page is sending your Spark core access_token to the web browser, where it arrives in clear text -- whether or not the browser is using SSL to access your HTML/js to get it there. Once it arrives and is decrypted (if sent over https) then it is there for anyone to see. All they have to do is is click, "View source." Obviously, PayPal et al would never allow such a thing.
Even in the case of third party access, like when you authorize YouTube to share a video on Facebook for example, only short-lived, temporary tokens are ever transferred and even then NEVER via or to the browser, because that would make them easy for anyone to see! Tokens are exchanged only ever from server to server, in the background, without going anywhere near the browser. Your web browser will be logged in (have valid sessions) with both Facebook and YouTube for the purposes of setting up the server-to-server exchange. But that is all. Facebook does not get your YouTube password. YouTube does not get your Facebook password -- and most importantly, no password or security access token is ever transferred out from either server to any web browser.
It may not display directly on screen. But it's right there in the source code. ANYONE who can see your web page and who has only the slightest knowledge of what HTML even is, can "view source" and see the token, any time they want.
Listen. If the browser knows the token -- through any means -- in order to allow your jQuery code to send it to api.apark.io -- then that browser is storing that token in plain, clear text, just a "view source" away. PERIOD.
Can someone else PLEASE step in and either call me on being an idiot or back me up here? I'm just trying to help someone understand basic HTML security. No offence, but I'm done.
Tell you what. Write it the way you think is secure and let me know (via PM if you prefer) the URL to access it. If you do not use a proxy and if you do allow me to view the page that contains the jQuery code to call the api server, then I will send you back the precise steps I took to get your access token. There will be less than three actions required on my part. No hacking. No decrypting. Just click, click, copy/paste.
That’s the best I can offer.
The steps would be.
- Load the page
- Hit F12
- View the JavaScript source. Either in the html page or in referenced js files
- Stick a breakpoint on the line where post is made or anywhere you think the access token is used.
- Use the web app until the breakpoint hits
- Hover your mouse over the variables. It will show you their values. One of them will be the access token.
Browsers do NOT secure data in any way. Even on banking sites, there is no data sent to the browser the bank isn’t happy for you to have.
The company that uses PayPal for example does not put their PayPal credentials in the javascript code. Not only that but the credentials never get to the browser in the first place.
I reckon I could get it down to about three steps, without any break-points. 
But sure. That would do it.
Thanks for weighing in.
EDIT: On a more positive note, let us not fret or get all down about any of this. Whilst there are things we can already do on our own servers to secure this issue, there are already indications from the Spark team in other threads that easier solutions are on the way -- including issuance of short term, one-off use access tokens and like, if only in the planning stages.
Meanwhile, if your (in the general sense -- IE whoever is reading this) web app is intended for people other than yourself to play with, then you might like to take a look at this project I found today. It's a short and sweet pre-written PHP web proxy agent, which looks to me like it could easily be adapted to our needs. In fact, it handles stuff we don't even need, like cookies. Unfortunately, I haven't yet had time to set up some tests and share how it goes together. But I will.
If your web app is intended only for your own use, then much of this discussion does not actually apply. Just make sure that you have to authenticate with your server in some standard fashion, before the page with Sparkcore control code is served and you'll be fine. You could rely on simply not telling anyone the URL for your app, for a while. But that won't be a good idea over the long term. Web spiders will find it, eventually.
P.S: I originally (two minutes before typing this) posted the wrong URL, to a similar but different project. The correct one is Google Code Archive - Long-term storage for Google Code Project Hosting. ... just in case someone got the errant version of the post in an email.
I will be the first to admit I am not a programmer of any kind. However, why would I give anyone my Joomla and protected directory credenitals where my protected code will reside. The real issue here is not that I can’t make a jquery post request submitted via a browser to the spark API without exposing the access token to the browser. The issue is when I am done only the NSA will be able to sniff my TCP/IP packets and subsequent POST Requests to the Spark API.
I agree 100% that what I am doing is not secure in the sense of just placing it in an unprotected directory on a server on the internet. Come on guys, I am not trying to stop that AT&T NSA room up in San Francisco that sniffs all internet traffic. My intentions are to make it easy for “ANYONE” to customize their own HTML interface with all options of using css with or without jquery.
Lets wait until I have completed my coding; protected the access token & all code from unauthorized access. The whole easy to use and modify package.
People should not have to become a PHP Proxy or Android Java Google Induced programmer.
“Balls in your court”
.
OK. So after explaining what the problem is and why you ideally shouldn’t ever do it … here is my SOLUTION for a secured proxy agent, to prevent sparkcore access tokens from ever needing to be sent to the browser, thus keeping them tightly secured …
Create a folder on your web server named /proxy and install the following two files …
EDIT: Replaced by later version in post, below.