summaryrefslogtreecommitdiff
path: root/test/unit
AgeCommit message (Collapse)Author
2014-07-14minor: fix identity test for storing certsAzul
we compare the cert that expires last to the one we just saved. So we need to make sure the one we saved is the one that expires last.
2014-07-12allow querying for the expiry of a particular fingerprintAzul
2014-07-12Identity view cert_fingerprints_by_expiryAzul
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.
2014-05-29clearify identity validationsAzul
Identity.new.valid? should not crash. So validate presence where needed and skip the other validations if the value is absent.
2014-05-29hand on errors from Email to Identity to UserAzul
errors.each iterates through all errors for all attrbibutes nicely.
2014-05-28adopt tests to new error messages for identitiesAzul
2014-05-26Merge pull request #163 from azul/feature/3398-save-hashed-tokenazul
hash token with sha512 against timing attacs #3398
2014-05-26hash token with sha512 against timing attacs #3398Azul
2014-05-19fix Email so User.new.valid? does not crashAzul
Email.new(nil) now returns an invalid email rather than crashing.
2014-05-13destinguish user.email from user.email_addressAzul
use the former if you want a working email account or nil, the latter if you want the email address associated with a given user no matter if the user actually has an email account or not.
2014-04-18change service level configuration strategyAzul
The changes to the configuration required some non minor changes to the platform and also added some flexibility we don't require yet - and thus some new possibilities for errors. So instead we still use the allow_..._certs and ..._cert_prefix options. They basically provide the framework in which service levels can operate. The service level configuration will not include the cert prefix anymore. It only states if the service level is rate limited or not. This avoids conflicts between the two configuration options. I also removed the anonymous service level entirely. It was also turning a boolean decision (do we provide anonymous eip or not) into something way more complex. Instead I added the AnonymousServiceLevel class to handle the corner cases for people who are not logged in. Furthermore i renamed the UnauthenticatedUser to AnonymousUser so it matches the Anonymous Service Level nicely. It's also shorter and more intuitive.
2014-04-10move certs into toplevelAzul
cleaned up all the engine stuff that was never really used. Afterwards there is not that much left that makes it into the toplevel.
2014-04-08moving users: app and test filesAzul
2013-07-24validations of email format and local domain moved overAzul
2012-09-27Adding in what used to be leap webapp demoAzul
we're merging repositories into one