tl:dr;
– If it’s on an HTTP address, consider it public info — usernames, passwords, HTML, and JSON results are all interceptable.
– unless you’ve secured it, your database usernames, passwords, and data are ALSO being sent in plain text.
tl:dr;
– If it’s on an HTTP address, consider it public info — usernames, passwords, HTML, and JSON results are all interceptable.
– unless you’ve secured it, your database usernames, passwords, and data are ALSO being sent in plain text.
So, four sessions today;
Modern JavaScript — Scott Allen. A nice overview of JavaScript and the right sort of patterns to use to build larger, more maintainable systems. Covered basics like function scope and closures, and then delved into more advanced topics like IIFEs (immediately invoking function expressions) and the revealing module pattern.
So the nice outcome here for me is that I can go back to work and say that, yes, these things are good and worth doing — an expert at DevWeek told us. And I know that sounds kinda funny, but it means that it becomes easier to build a consensus amongst a team. Instead of saying ‘Steve’s an opinionated developer and has his way of doing things, but I’ve got my way,’ members of a team can feel more like they are following an independent best practice.
Temporal data in SQL Server — Dejan Sarka. This was a really interesting one. Dejan Sarka is a man who knows his stuff. Check out the book list. He wrote the Microsoft books on the internals of SQL Server 2005 and 2008.
Dejan Sarka’s presentation was about how to deal with timed data in SQL Server — a server which doesn’t include a timespan-like datatype. What he outlined was a system for building systems with really solid time-based support. The tl:dr; is this; identify a ‘time quantum’ like one day, and give each day an integer value. Then define a CLR datatype with a start-day and an end-day, forming a scalar value that can be used to represent a time range and which can be joined, unioned, etc — all the operations you need for querying. Now you can include ‘Interval’ columns in your database and use the interval as part of your key, for joins, etc.
Patterns and techniques for securing REST/HTTP-based services and (ASP.NET) Web APIs — Dominick Baier. The surprise big hit of the conference for me. This one was held in one of the big cinemas, and it got a lot of interest. It seems that the ASP.NET stack doesn’t have that strong a security story, and Dominick gave a nice presentation of how you might successfully secure a web service using OAuth2 and claims-based authentication. One to use, I think.
RESTful architectures on the Microsoft stack — Hadi Hariri. This one was interesting. Before I went, I thought that there was a danger that this would be a repeat of material from Christian Weyer’s talk yesterday and Dominick Baier’s talk today, but it took a different tack and I’m glad it did. The first half of the talk helped explain the difference between REST, which is a very particular design pattern for designing HTTP-based APIs, and non-REST HTTP APIs. The short thing here is that if you’re not sure if you’re doing REST, you aren’t. REST is very particular, has a fixed number of principles that need to be followed, and if you haven’t studied them and made sure you’re doing them, then you aren’t doing them.
The second half of the talk went into how you might go about implementing true REST on the parallel Microsoft stacks of ASP.NET MVC, and ASP.NET Web API — two products that are remarkably similar superficially, but which need their own different handling to become RESTful.
Now, the question is, do you want to be RESTful? Is it worth the effort, if you’re already doing an HTTP API? That question you can only answer for yourself, but it’s worth noting that it’s not free — it’s a re-write you need to do to your existing HTTP API.