Age | Commit message (Collapse) | Author |
|
An expired token was removed (probably by automatic cleanup) while processing it. So the webapp crashed due to a couch 404.
We're preventing that by rescueing from a 404 on Token.delete by default.
|
|
uniq! is probably not any faster than just checking include?
|
|
|
|
|
|
by_user_ids_to_show_and_created_at view is right before issuing pull request.
|
|
sorted by date (although are not now.)
Also, rather than use whenever gem, will have cron job created to call task.
|
|
|
|
if doc.keys has not been set doc.keys[pgp] will raise an error.
We always upload the key after signup - but this might fail and there is some time in between. Not checking for this condition lead to errors in the couch logs.
|
|
|
|
Authentication still remaining piece.
|
|
|
|
|
|
|
|
will later be replaced.
|
|
|
|
messages within the webapp.
|
|
|
|
|
|
|
|
parts, but seems like okay generic start for now.
|
|
|
|
|
|
refactor: prepare validations of the uploaded pgp keys
|
|
* 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.
|
|
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.
|
|
addresses with uppercase letters in local part.
|
|
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.
|
|
Bugfix/3623 teardown test data properly
|
|
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 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.
|
|
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.
|
|
|
|
|
|
|
|
Just altering identity.keys did not mark identities as changed. Also we now have a sane default for keys.
|
|
|