Age | Commit message (Collapse) | Author |
|
Feature/billing past due subscriptions
|
|
blacklist system logins for aliases and logins
|
|
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.
|
|
We were not encoding the srp password properly before. So umlauts in the password would cause the login procedure to fail.
|
|
|
|
addresses with uppercase letters in local part.
|
|
This also helps with the failing integration test. We needed a way to tell the ajax request was back. Observing the button state now works for that.
|
|
One failing integration test still needs to be fixed
|
|
an identity's destination is a valid Email.
|
|
|
|
|
|
|
|
LoginFormatValidation. However, this is not how we will want it eventually.
One issue is that the errors messages are set on login, rather than the appropriate field.
|
|
|
|
emails.
|
|
There's no non api sessions resource anymore.
|
|
Bugfix/3623 teardown test data properly
|
|
Token expiry
|
|
[skip ci]
|
|
|
|
So the #create and #update actions were not needed anymore. Also removed the tests
|
|
We have a lot of things that act upon a user record and one or more of it's identities at the same time:
* Sing up: Create a user and it's initial identity
* Rename: Change the username and create a new identity, turn old into an alias
* Cancel Account: Remove user and all their identities.
In order to keep the User and Identity behaviour isolated but still have a this logic represented in a sinle place the Account model deals with all these things.
We could have overwritten the User#create, User#update and User#destroy methods instead. But then we would always create identities, even if we only need a user (for example in tests).
|
|
|
|
This will return the user. But we can add timestamp validations and updates here.
|
|
identities controller will replace it.
|
|
|
|
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.
|
|
|
|
This way we can stub the token to return the user directly. Stubbing User.find_by_param is not a good idea as it will make all calls to User#find_by_param with a different id fail.
|
|
So far we allow two mechanisms of authentication:
* session based
* token based
If token fails session will be atempted in most cases. So we can't just redirect here or we get a double render error.
|
|
|
|
|
|
|
|
|
|
use the same login validations on sessions and users
|
|
|
|
That's the only meaningful response.
|
|
The session ones were outdated so valid usernames could not login if they contained a '.'
Refactored so both models use the same module for this validation to ensure consistency.
|
|
|
|
Key must end in _html so the html doesn't get escaped.
|
|
disable, must remove billing engine from Gemfile (and re-bundle)
|
|
customer.
|
|
|
|
|
|
PGP setting has been moved into account settings. It's using the API now issueing an Ajax request without any visual feedback.
This obviously is not what we want but it hopefully suffices for uploading gpg keys for testing purposes before the Identity UI is in place.
|
|
Just altering identity.keys did not mark identities as changed. Also we now have a sane default for keys.
|
|
|
|
We'll want to get rid of the #public_key and #public_key= functions but they are still used from the users controller. We'll probably have an identity controller instead at some point.
|
|
|
|
|