| Age | Commit message (Collapse) | Author |
|---|
|
There are some places where we only want to require login unless you can use EIP anonymously. So far we had an anonymous_certs_allowed? method in all these controllers. Now it's replaced with ApiController#anonymous_access_allowed?. The naming better reflects that there might be other services that allow anonymous use at some point.
This also fixed a typo name -> @filename that broke the ConfigsController.
|
|
require_login is require_token for the api controller
It also skips the verify_authenticity_token before filter.
So all Subclasses of the ApiController will only support token auth.
Also made the V1::UsersController a bit more strict. Now way for admins to alter other users through the api. We don't support that yet so let's not allow it either.
|
|
We create them. let's reflect that in the verb.
|
|
The changes to the configuration required some non minor changes to the platform and also added some flexibility we don't require yet - and thus some new possibilities for errors.
So instead we still use the allow_..._certs and ..._cert_prefix options.
They basically provide the framework in which service levels can operate.
The service level configuration will not include the cert prefix anymore.
It only states if the service level is rate limited or not.
This avoids conflicts between the two configuration options.
I also removed the anonymous service level entirely.
It was also turning a boolean decision (do we provide anonymous eip or not) into something way more complex. Instead I added the AnonymousServiceLevel class to handle the corner cases for people who are not logged in.
Furthermore i renamed the UnauthenticatedUser to AnonymousUser so it matches the Anonymous Service Level nicely. It's also shorter and more intuitive.
|
|
Null Pattern for current_user - use it to get rid of some conditionals
|
|
cleaned up all the engine stuff that was never really used.
Afterwards there is not that much left that makes it into the toplevel.
|
