| Age | Commit message (Collapse) | Author |
|---|
|
|
|
to use twitter secrets-file has to be created
|
|
- only bearer token is needed to access Twitter API
|
|
|
|
This avoids overwriting the PROVIDER_JSON constant in the
StaticConfigController and thus fixes test warnings.
Also moved away from using instance variables in the
ControllerExtension::JsonFile - instead querying the corresponding
functions now - less sideeffects and easier stubbing.
|
|
token, "tmp" users are users that exist only in tmp db, "test" users are either tmp users or users named "test_user_x"
|
|
are configured in the static config, to be used for infrastructure monitoring.
|
|
Through the config param 'invite_required', providers can decide whether users need to provide an invite code upon signup.
The default setting is false.
|
|
|
|
|
|
|
|
client_cert_lifespan config option.
|
|
https://github.com/azul/leap_web into develop
|
|
Also moved the location of the config files into a configuration setting.
|
|
is a reserved username that can't be registered.
|
|
- default is true
- See issue #5217
- See companion change in leap_platform.
|
|
|
|
We should respect the users choice. We can still get their email from the user id if we really need to.
|
|
cost -> rate
quota -> storage
|
|
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
|
|
this still allows us to do current_user.service_level.
Have not gone through the rest of the code yet.
Only made sure logged_in? now tests for is_a? User instead of !!current_user
|
|
cleaned up all the engine stuff that was never really used.
Afterwards there is not that much left that makes it into the toplevel.
|
|
|
|
response headers (in particular, 'X-Minimum-Client-Version'). It must now be placed in config/provider/provider.json
|
|
* set locale based on request header
* enforce locale path prefix when current locale is not the default
* note: don't use root_path anymore, instead use home_path
|
|
testing gem phantomjs-binaries)
|
|
APP_CONFIG[:braintree] into APP_CONFIG[:billing][:braintree]
|
|
Bugfix/4703 disable unsupported settings
|
|
with tests
|
|
* in case the user has a session id, keep it but proceed without a session
* in case we can't initialize the models proceed
* if APP_CONFIG[:reraise_errors] is set we'll crash instead in the latter case
default to reraise errors in dev and test environments.
|
|
service level code won't break anything if it isn't set in the config.
|
|
* stores desired & effective service level
* whenever desired level is changed, effective level will be updated
* allows user to set their desired service level
* allow admin to update desired & effective service level
|
|
|
|
They did not point directly to the download.
|
|
This way we won't have to redeploy once the new links to the windows and the android version are there.
Also this obviously offers more flexibility for providers.
|
|
We blacklist based on three things:
* blacklist in APP_CONFIG[:handle_blacklist]
* emails in RFC 2142
* usernames in /etc/passwd
The latter two can be allowed by explicitly whitelisting them in APP_CONFIG[:handle_whitelist].
We stick to blocking names that have been configured as both blacklisted and whitelisted - better be save than sorry.
|
|
|
|
|
|
specify which gems for which environments.
Here, we have the billing gem included for the development and test environments only, hardcoded in the Gemfile.
Then we show the links to billing based on a config file setting. The setting itself could be used to specify different types of billing, but isn't yet.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
does common name matching)
|
|
|
|
|
|
|
