| Age | Commit message (Collapse) | Author |
|---|
|
are configured in the static config, to be used for infrastructure monitoring.
|
|
the only race condition I can think of here is this...
somebody tries to authenticate with a token that is almost expired.
auth checks and notices it is not expired yet so starts to prolonge it.
Before the polonged token is written to the db the cleanup script discovers that it has just expired.
prolonged token is written to the db
cleanup script fails to delete it from the db as it has been updated.
So what we want in this case is to keep the token alive as it was renewed in the last minute.
|
|
get re-enabled.
|
|
anymore. closes #7690
|
|
|
|
https://github.com/Alster-Hamburgers/leap_web into remove_couponcode
# Conflicts:
# lib/tasks/invite_code.rake
|
|
Braintree_implementation
|
|
Id is set = invite code to make it easier to delete the invite codes that get created during the leap platform tests (because this avoids having to look up ttheir id each time).
|
|
Replacing the Coupon Code gem with base64/securerandom as suggested by Elijah.
|
|
Id is set = invite code to make it easier to delete the invite codes that get created during the leap platform tests (because this avoids having to look up ttheir id each time).
|
|
Replacing the Coupon Code gem with base64/securerandom as suggested by Elijah.
|
|
|
|
This will simplify invite code deletion after running tests.
|
|
Removing some superfluous code, mostly, and structuring tests better.
|
|
|
|
|
|
|
|
|
|
The rake task now takes a second (optional) argument that sets the number of uses per invite code.
If this is omitted, the default number of uses is 1.
(This commit also contains some minor code cleanup that removes some stuff that I'd commented out but not removed.)
|
|
Introduce a invite_max_uses property to invite codes to allow admins to set a maximum number of uses for invite codes.
|
|
Through the config param 'invite_required', providers can decide whether users need to provide an invite code upon signup.
The default setting is false.
|
|
|
|
|
|
Validation should only happen for new records
User invite code was nil for invalid invite codes
Adding missing tests
|
|
We introduced a count on invite codes to make sure that (at the moment) codes can only be used once. (The code will also allow multi-use codes in the future.)
Also, some of our validations weren't validating against the correct data, which is now fixed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tmp db for test users.
|
|
client_cert_lifespan config option.
|
|
problem creating the account.
|
|
closes #6550
|
|
|
|
|
|
Also move complex identity views into js designs.
Includes test.
Here's how you would query it from outside rails:
```
$ curl
'localhost:5984/identities/_design/Identity/_view/cert_fingerprints_by_expiry?startkey="2014-07-05"'
{"total_rows":4,"offset":1,"rows":[
{"id":"6c9091d4f13eaeaa6062c9d0528fd34d","key":"2014-07-05","value":"fingerprint"},
{"id":"6f3aa93828b4f6978d551f2623b9d103","key":"2014-07-05","value":"fingerprint"},
{"id":"b6cafacfa65042679691cd5065fb19e3","key":"2014-07-07","value":"fp"}
]}
```
Note that the expiry will be used as the key. So you should use the
current data (or yesterday) as the startkey to get all fingerprints that
have not expired yet.
The fingerprint itself is in the value. No need to include docs.
|
|
We used to store the creation date but this way it's easier to query for non expired certs
|
|
Allow admins to unblock handles
|
|
|
|
|
|
There's an identities tab now for admins that will allow unblocking blocked handles. It should be easy to expand for aliases and forwards and other types of actions such as editing.
|
|
the errors on the object if not saved.
|
|
identity errors to user and add identity class hook.
|
|
Identity.new.valid? should not crash. So validate presence where needed and
skip the other validations if the value is absent.
|
|
|
|
errors.each iterates through all errors for all attrbibutes nicely.
|
|
Users now always check if their identity is valid. We need to make
sure this works if the user is a new record and once it has been
persisted.
While the user is a new record the identity will have no user_id.
Old identities that are left to block the login of a user who
canceled their account also have a blank user_id. They still should
render the new identity invalid so the user can't be saved with a
login that has been reserved.
Once the user has been persisted we set the user_id on the identity
and save it too when creating an Account. This allows us to create
a plain user and save it and it will still have an in memory identity
only. But the default is to create the user by means of creating an
account so an identity will be created as well.
|
