leap_web.git/users/app/models, branch 0.2.6

blacklist system logins for aliases and logins

2013-10-17T10:05:26+00:00

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.

Since local part of email is case sensitive, want to allow remote email addresses with uppercase letters in local part.

2013-09-26T19:06:25+00:00

This ensures that email addresses contain only lowercase letters, and that an identity's destination is a valid Email.

2013-09-23T19:23:08+00:00

Merge branch 'develop' into feature/only_lower_case_aliases

2013-09-19T19:07:25+00:00

user.account shortcut to Account.new(user)

2013-09-18T08:27:19+00:00

For moment, have identity's address handle aliased from login so we can use LoginFormatValidation. However, this is not how we will want it eventually.

2013-09-05T21:00:50+00:00

One issue is that the errors messages are set on login, rather than the appropriate field.

Ensure that address in identity really is a LocalEmail.

2013-09-05T20:56:02+00:00

Move handle method to Email model and have it work for local and non-local emails.

2013-09-05T20:10:23+00:00

Merge pull request #73 from azul/bugfix/3623-teardown-test-data-properly

2013-09-03T17:48:13+00:00

Bugfix/3623 teardown test data properly

Account: Composition to handle User and its identities

2013-09-03T06:54:25+00:00

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).