In the past when we wanted to add a membership section to our site we only had one option – use our platform form-based login. But things today are a lot more complicated. With the increase Internet use, the rise of mobile devices, social network identities and external services, membership system today need to support many complex scenarios.
Up until now, we talked about where to save the “session state” – on the server (part 1) or on the client (part 2). But the user identity and his permissions are not all the data which we may need to store.
In Part 1 (When the Cookie Crumbles) we saw what issues can happen when using Session ID Cookie and storing the session state on the server. In this post, we will learn about client-side sessions, and how they can solve those problems.
Adding membership support to sites has changed drastically over the last decade. Instead of basic authentication with username and password, modern sites are now required to support modern authentication protocols like OAuth, OpenID and occasionally even SAML. Besides bringing new ways for sharing users identities between sites, these protocols also bring a new concept with them – the client-side session. This idea is in the heart of those protocols, and understanding it is the first step in learning how they work.
Microsoft Graph is here to unite Azure & Office 365 data under a single roof. It is a simple REST API and Microsoft provided many examples on how to use it including an interactive Graph Explorer which allows us to discover the different methods. Using the API is as simple as…
Question: when is the work on a site is finished?
Answer: When no one uses it anymore.
There is a saying: “if a business doesn’t grow, it dies”. And these days businesses need to run twice as fast in order to stay in the same place.
In the previous chapter, we learned that Reliability helps us to ensure the system will work correctly even in a case of data corruption or component failure. But even if the system will work correctly for one user doesn’t mean it will still work nicely when many users want to join in. **Availability** measure how *available* is the system for everyone who wants to use it. High availability systems can offer the same smooth experience regardless of how many users simultaneously use them or where they are on the planet.
Availability and Reliability usually complement each other, but they can be mutually exclusive. A system can offer great reliability for a fixed number of users, but may be limited to the maximum total/concurrent users or suffer from degrading experience. High availability system can support many users at the same time without affecting performance, but even a small malfunction can bring the entire system down. This is why often the Reliability and Availability aspects of the system supplement each other in order to deliver the best possible system stability at scale.
Many times developers (and sometimes even project managers) think of a site as a “product”, which means once it’s live in production they can stop thinking about it and move to the next project. But in fact, websites are more like *services* and keeping them working as expected in the long-run is a full-time job and where the real challenge starts.
Keeping the site running usually falls into IT department, although in recent years it became more of a combined effort (this is the topic of the next chapter, Delivery).
It can be divided into 3 parts: Reliability, Availability, and Delivery:
Question: What the following companies have in common: Verizon, AA, OneLogin, Chipotle, Bell, PlayStation, VTech, Cex, and now Equifax?
Answer: they were all had major data breaches in 2017 alone.
As for August 2017, more than 3 billions user accounts were hacked in over 3,000 large sites breaches.
Over the past 20 years, sites usage has become mainstream and many people were starting to depend on them for their daily activities. As more people were starting to use them, they had a real effect on people life. And this is when sites started to develop some darker practices. From email spam to users privacy violation and even using psychology in order to trick people into doing things they wouldn’t normally do, companies began abusing their powers and the trust of their users.
This is when it was apparent that some kind of regulation had to be made, and that regulation and how it affected site design is the topic of this chapter.