Emergency Mode was introduced in aID and the Amedia publishing stack to minimize the impact on users when we are in a situation when things are failing and our redundant systems for some reason is not working as designed. aID has a good track record when it comes to stability, but the impact on the user experience is very large when it’s failing, so it’s important to have a contingency plan to ensure that the user gets access to paid content at all times. A failing login system is really annoying!
When in emergency mode, users will not be able to log in, but will be greeted with a dialog informing that we are currently experiencing problems. Normally users won’t see this dialog because what they care about is consuming content, and all access checks are turned off during emergency mode, so they will instead see the content while being logged out. Our goal is to hide this from the user as much as possible, but when it’s not possible we want to make sure the user knows what’s going on, and that the user didn’t do anything wrong to get to the error dialog.
Amedia’s publications will open up access to all pluss articles, magazines and ePapers (in apps and on desktop) when in emergency mode. This will hide the problem as much as possible from the end users. We encourage third parties to do the same.
There are two ways to detect emergency mode:
.2Look for the HTTP header called x-aid-emergency-mode in HTTP responses
If either the status endpoint or the header contains true, aID is in emergency mode. Both are set using the same logic, so they will both either be true or false at the same time.
All third parties can decide how to handle emergency mode. aID makes sure that when users are sent to OAuth authorization during emergency mode, the user will see a friendly dialog explaining that we are experiencing problems. But the experience can be improved upon by not even sending them to aID.
When checking aID endpoints, check the response for the x-aid-emergency-mode header. If present, don’t interpret errors as indicating that the user is no longer logged in. Instead, hide any user information like name, email etc. from the user and make sure the user gets access to anything he wants. This will make sure that the experience for logged in users is as good as possible.
For users without an access token it’s normal to show some kind of dialog to the user when trying to access premium content. This dialog will normally ask the user to log in. By checking the response from https://www.aid.no/aid/status/emergency, either before showing the dialog, or periodically to update some local state, showing this dialog can be avoided when it’s known that login will fail for the user. Instead the user should get access to the content, even if the user might not be a paying subscriber.
The idea here is to treat unknown users as paying customers. We believe that keeping a paying customer from getting access to paid for content is very bad, allowing a potential customer to temporarily get access to content without paying is less bad. In some cases the value of the content might be so high that this reasoning is no longer valid.
A potential issue here is that a user might figure out that access to premium content at a third party can be gained through a DDOS attack or similar against aID. Our assessment is that this risk is outweighed by the benefit for the users in more common infrastructure failure situations. And any attack on aID will be reported to the authorities.