Since I had issues finding a good explanation on how to tie together a controller and a directive with isolated scope I decided to create my own blog post on this subject. This repo contains a runnable example of the solution. It contains a Spring Boot Web Application that can be started to act as a HTTP server but all the interesting stuff is in the src/main/webapp folder.
To create modular code with AngularJS you want to create reusable components; directives. Directives should not depend in any way on the parent controller. They should not be able to see any of the parent scope unless it’s explicitly provided to them. To do this Angular directives can have an isolated scope (which in my opinion should be the default). Continue reading →
This second part of the Stateless Spring Security series is about exploring means of authentication in a stateless way. If you missed the first part about CSRF you can find it here.
So when talking about Authentication, its all about having the client identify itself to the server in a verifiable manner. Typically this start with the server providing the client with a challenge, like a request to fill in a username / password. Today I want to focus on what happens after passing such initial (manual) challenge and how to deal with automatic re-authentication of futher HTTP requests.
Session Cookie based
The most common approach we probably all know is to use a server generated secret token (Session key) in the form of a JSESSIONID cookie. Initial setup for this is near nothing these days perhaps making you forget you have a choice to make here in the first place. Even without further using this “Session key” to store any other state “in the session”, the key itself is in fact state as well. I.e. without a shared and persistent storage of these keys, no successful authentication will survive a server reboot or requests being load balanced to another server.
Today with a RESTful architecture becoming more and more standard it might be worthwhile to spend some time rethinking your current security approaches. Within this small series of blog posts we’ll explore a few relatively new ways of solving web related security issues in a Stateless way. This first entry is about protecting your website against Cross-Site Request Forgery (CSRF).
Recap: What is Cross-Site Request Forgery?
CSRF attacks are based on lingering authentication cookies. After being logged in or otherwise identified as a unique visitor on a site, that site is likely to leave a cookie within the browser. Without explicitly logging out or otherwise removing this cookie, it is likely to remain valid for some time.
Today a colleague asked a group of front-end developers how he would create a superelipse.
His current solution was to use a svg mask to remove all non essential visual information. This solution however had a setback, because we used a mask to shield the edges we had no real transparency. Thus we were unable to effectively use it on more graphic backgrounds.
I however thought it should be able to use canvas to provide the solution. The code below is my solution. Continue reading →
We can use the tel: URL scheme for phone numbers in HTML. Just like the mailto: URL scheme will open the default mail application will the tel: start a telephone call. If the HTML page is viewed on a mobile phone and we select a link with the tel: scheme we can immediately call the number following the scheme. On a desktop computer a VOIP call will be initiated.
We can use hyphens in the phone number for readability, they will be ignored when the call is made. For example the imaginary phone number 123456789 in the Netherlands can be used as shown in the following HTML snippet:
So what to take away from the SpringOne 2012 conference?
The overall theme of this conference is the changing world we as developer find ourselves in. As we all know the world of software development is always evolving at a rapid pace. This evolution always leads to changes in requirements and new solutions to breach the gap. In some cases these evolutions require a new way of thinking. The essence of this SpringOne is about the latter. The current evolution is driven by:
increases in data quantity
the explosion of browser enabled devices
the request for higher quality of service (an application needs to be able to survive outage of a data center)
near real time delivery of contextual information and social integration in frontends.
The combination of these new demands and requirements leads us to a so-called paradigm shift. These problems cannot be solved with past (or current) architecture. So we need to look at our applications in a new way. Building and modularizing them to account for scalability because that seems to be the answer to the questions asked.
We need to start thinking in federations to persist information across cloud instances. Size and package application modules so they can be scaled separately.
At his SpringOne conference the tools and the methods needed to do this were show cased. Adrian Colyer’s keynote on day two gives us a good idea of what Spring offers to help us cope with these changes and as always make our life easier.
But rather then removing all the logging i’ve found there’s an easy solution. Building yourself a logger like structure which checks the existence of the console before writing. That way you can add logging statements without crashing the entire application. Continue reading →