Recently, I was reviewing some old code to see why it was performing poorly. The code in question was Database specific and was using an Entity Framework 4.4. Of course, many people wanted to immediately blame it all on Entity Framework.
Personally, I’m not so quick to condemn a framework. Frameworks usually do what you tell them to do, but only as well as you instruct them. From my experience, most of the time when a framework behaves badly, it’s not the framework’s fault. It’s usually due to poor utilization and understanding of the framework.
Here’s something I learned about Url hashtags a while back that seemed worth sharing.
As you may know, hashtags are never sent to the server. There is, by regular browser redirection, no way to get hashtag information to the server.
For a client-side script based web application that uses hashtags, obviously, this presents a challenge. Even if all you want is a redirect url on login, it can’t utilize the hashtag.
One work-around that I found that works well is to redirect to a page that has a hidden HTML input which you can stuff the hash (url encoded) into and then post that as a named/value pair to the server.
After my previous post regarding Secure Token Services / SSO, I have been diving deeper into OWIN to understand its capabilities further.
As I mentioned, the STS system I devised is still using FormsAuthentcation. As a consequence, the relying applications are also dependent on FormsAuth. Upon further inspection, I found that this is redundant. It turns out that OWIN was doing more than I initially divined. Additionally, from all that I have read, it appears that Microsoft’s vision is to completely supplant, and retire, FormsAuth. This, obviously, could be a point of contention if one ties their authentication system into FormsAuth.
Earlier this week, an article about technology choices was floating around the office: Choose Boring Technology
The premise of the article focused on technology choices and explained why sticking to tried and true technologies has merit. In my own experience, and in the same week, I find this article to be very relevant and had my own correlating experience.
For the past week, I’ve been working on creating a Single SignOn (SSO) system with ASP.NET. One joke around the office is that SSO could also stand for Seldom SignOn. Essentially, we want to make securing applications as painless for the user as possible. Along the way, being able to generate secure tokens through a Secure Token Service (STS) seemed advantageous as well.
Interestingly, it still comes back to cookies. Tokenizaiton is only useful for securing API’s. That is to say, attaching an Authorization Header to an API call is straight forward, but it’s not feasible to attach one to a user’s initiated browsing.
While working with an Angular application that involved selecting rows in a table with checkboxes, I found that the requirements necessitated having a ‘select all’ checkbox.
Selecting all elements is a common, and usually pretty easy, mechanism to incorporate. But, if you want an indeterminate, or tri, state, for your top-level checkbox selector, it becomes a little more involved.
When I’m online with my banking site, or Pandora, I occasionally get those nice dialogs asking if I’m still around after being idle for a while. Sometimes, I think it’s a nuisance, but it can be a helpful security measure. It can also be beneficial in SPA-type applications.
With SPA’s, the user can perform so many actions in the browser that never make requests of the server. As a result, if we’re using a cookie-based security mechanism that has a short expiration time, they could be effectively logged out and not even know it.
This is a problem.