| Age | Commit message (Collapse) | Author |
|---|
|
* 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
|
|
Feature/cleanup expired tokens
|
|
|
|
|
|
|
|
In order to keep the users engine independent of the tickets engine i added a generic load hook to the account model. The tickets engine then monkeypatches the account destruction and destroys all tickets before the user is destroyed.
The tickets are destroyed first so that even if things break there should never be tickets with an outdated user id.
I would have prefered to use super over using an alias_method_chain but I have not been able to figure out a way to make account a superclass of the account extension and still refer to Account from the users engine.
|
|
This is mostly for cleaning up after tests so far. But we might expand this to destroy all identities disabled before a certain date.
|
|
|
|
This way the identity model defines how identities should be disabled. We currently still destroy them. But it will be easy and nicely isolated to change this next.
|
|
Also fixes a cornercase when admins deleted their own account. So far they would be redirected to the users list - which then refused access. Now they'll be redirected to the home landing page as well.
|
|
|
|
including test
refactored error display some
|
|
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.
|
