The second half of the morning talks for CascadiaJS Browser Day.
Martin Gontovnikas: Death to Cookies: Long Live JSON Web Tokens
How does the web work now? Start with browser and server. To buy something, you have to log in.
- POST (to server) /users/login with username and password
- Creates a User session (at server)
- Returns a logged in cookie to the browser
- Do an authenticated request. Sends the cookie. (back to server)
- Server will grab the cookie, check against the user session in memory.
That used to work really well. However, now starting to do a lot within the browser and cookies don’t work as well with that.
Problems
1. Cookies don’t play well with CORS.
2. Cookies require stateful servers. Needs in memory session (vs. stateless where response is always the same). Creates problem when using multiple servers, because always have to go back to the same server. HTTP is a stateless protocol
3.APIs should be stateless
4. Cookies don’t flow. If want user ID to flow from one server to another, it doesn’t work. Need API or framework, but doesn’t work well.
Using JSON Web Token
A better approach is using JSON Web Token Authentication.
Using spec from IETF, became final 4-5 months ago.
Specify algorithm, type, payload (information), secret (only known by server).
Now, the process
- POST /users/login with username and password
- Server creates a JWT with a secret
- Returns the JWT to the Browser
- Brownser sends the JWT on the authorization header.
- Check JWT signature (if created by the server, server knows secret). Get user information from the JWT.
It has everything to identify. Don’t need database environment to save information of all active sessions.
Live Coding Example!
All it means to be logged in is to have a JWT in local storage. All it means to log out is to delete the JWT.
Can also route user to the login page when JWT does not exist or if it is malformed.
Even if someone inserts a different JWT with the same secret phrase, will not work because it will not match the JWT on the server.
http://auze.ro/cascadia-jwt
David Catuhe 3D everywhere with WebGL and Babylon.js
WebGL is a JavaScript API based on OpenGL ES 2.0 standardsized by Kronos Group which works on all major browsers.
Can be used directly, but need to handle everything except the rendering.
Wrote Babylon.JS to prevent people from having to use WebGL directly. Open Source project. http://www.babylonjs.com & http://cdn.babylongjs.com/2-1/babylon.js
How to use it? include one file and you’re ready to go
[code]
<script src-"babylong.js"><\script>
[/code]
To start byablon.js, you need to create an engine object:
[code]
var engine = new BABYLONG.Engine(canvas, true);
[/code]
The engine is your friend who knows how to deal with the maths and the weird stuff that happens between the CPU and the GPU.
Babylong.js is a scene graph. All complex features are abstracted for you.
Handling rending can be done in one line:
[code]
engine.runRenderLoop(function() { scene.renderer(); });
[/code]
Live coding example!
Define scene, shape, and material. Material can be changed, frame, colour, texture, transparency. Can play with position, animate. Can create a particle system.
Want to experiment? Play, save, share. http://babylonjs.playground.com
Want to go further? http://babylonjs.com/cyos
Assets for tools to export content that will generate babylon.js files: Blender 3D, 3DS Max, Unity 5, Clara.io
Export can then be imported into the Babylon.js sandbox to test.
.Babylon Formats: Babylon: scene and JSON, Incremental Baby: scene, data file per mesh, JSON for both; Binary: scene, data file per mesh, JSON format for scene, BINARY data for mesh, data loaded directly to GPU; each makes the files smaller
Playing with inputs: pointer events, device orientation, virtual joysticks, anagyph, VR, gamepad to control camera
WebAudio: can be added to set scene/mood
Audio Analyzer with visualization in 3D
Myles Borins: It’s not me it’s you: on the fallibility of large systems
Artist, musician, developer.
Why SHould You Care?
Any given element of one system is simultaneously an element in any one other system. – The Systems Bible by John Gall
When we write code, we create systems. Every piece needs to line up perfectly for the system to work. If any part of that system breaks, you are going to have a bad time.
How do you believe me?
Immediately assumed did something wrong when someone posted a major bug. After some time, found out one was using SVG, old one was using PNG. Firefox had a SVG bug.
As systems grow in size and complexity they tend to lose basic functionality.
Chokidar
neat wrapper around node.js fs.watch part of browserify.
Why do we have to wrap fs.watch? File watching is not standard in OSX.
POSIX is a set of IEEE standards make basic things across systems in Unix, but OSX does not quite follow those rules.
Consequence for fs.watch on OSX: only poll based, doesn’t report filenames or events at all, etc. fs.watchFile almost as bad.
Every picture tells a story but not the same story.
Use browserify and watchify for all the things. Using a lot of modules in npm. These systems slowly but surely start to get very complex.
A lot of symbolic links, and things started going very wrong. Turns out, the feature relied on was working, but not supported.
Created Uatu, watcher to watch all the watchers. Unity test suite to test each layer of the stack for filewatching. Use test suit with git bisect (give hash of what works and doesn’t search along history to flag what’s wrong) to find part of the code that was braking.
In order to succeed it is necessary to know how to avoid the most likely ways to fail.
Take Away
Don’t forget you are always in a system. Everything you code is within a big stack.
Break Time
Grab a friend and fly over to lunch.
