Age | Commit message (Collapse) | Author | |
---|---|---|---|
2014-02-10 | require token in messages controller | Azul | |
2014-02-10 | require token when logging out via API | Azul | |
2014-02-10 | require token when updating user via API | Azul | |
2014-02-10 | rename authorize to require_login | Azul | |
authorize_admin -> require_admin also add require_token which will ensure token has been used for auth. | |||
2014-01-09 | Some more cleanup, but still want to make sure ↵ | jessib | |
by_user_ids_to_show_and_created_at view is right before issuing pull request. | |||
2014-01-07 | Some refactoring, to simplify user model, optimize, and allow messages to be ↵ | jessib | |
sorted by date (although are not now.) Also, rather than use whenever gem, will have cron job created to call task. | |||
2013-12-31 | Add authentication to API, but not sure it is best way. | jessib | |
2013-12-31 | Cleanup of code for messages API and cron job for 1 month payment warning. ↵ | jessib | |
Authentication still remaining piece. | |||
2013-12-30 | Change structure to be more no-sql-y, rather than relational. | jessib | |
2013-12-24 | Catching some corner cases & new tests. | jessib | |
2013-12-24 | Add API tests and some refactoring of messages so we can get a user's ↵ | jessib | |
messages within the webapp. | |||
2013-12-24 | API method to mark a user's message as read (will refactor) | jessib | |
2013-12-24 | Initial start to messages API. | jessib | |
2013-11-06 | use the account lifecycle from UsersController#destroy | Azul | |
2013-09-24 | use token auth when accessing the api from webapp | Azul | |
One failing integration test still needs to be fixed | |||
2013-09-18 | user.account shortcut to Account.new(user) | Azul | |
2013-09-03 | Merge pull request #73 from azul/bugfix/3623-teardown-test-data-properly | jessib | |
Bugfix/3623 teardown test data properly | |||
2013-09-03 | clearify usage of V1::UsersController#index for autocomplete | Azul | |
[skip ci] | |||
2013-09-03 | Account: Composition to handle User and its identities | Azul | |
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). | |||
2013-08-27 | Merge branch 'master' into billing_with_tests | jessib | |
2013-08-21 | return 204 NO CONTENT on API logout | Azul | |
That's the only meaningful response. | |||
2013-07-24 | separate signup and settings service objects for user | Azul | |
2013-07-24 | removed email settings controller and views | Azul | |
PGP setting has been moved into account settings. It's using the API now issueing an Ajax request without any visual feedback. This obviously is not what we want but it hopefully suffices for uploading gpg keys for testing purposes before the Identity UI is in place. | |||
2013-07-17 | fix account flow integration test | Azul | |
not really sure what to do if the second step of srp auth is repeated. | |||
2013-07-04 | user tests -- user update has been moved entirely to api controller, so fix ↵ | elijah | |
tests to reflect this. | |||
2013-07-04 | fix user typeahead | elijah | |
2013-07-04 | users engine changes - rewrite of the views, separate email settings to a ↵ | elijah | |
separate controller, make users_controller html only and v1/users_controller json only. | |||
2013-04-09 | return token on successful login via api | Azul | |
2013-04-02 | send salt on Session#create without srp ephemeral A | Azul | |
2013-02-26 | api for sessions fixed | Azul | |
* now we return the user id on login * allow a destroy request for logging out * added test for api sessions controller | |||
2013-01-31 | Remove public key if the key is passed as nil, but not otherwise. | jessib | |
There was a weird case with reloading the user in the test if the public key had been unset. | |||
2013-01-29 | A user's public_key is the only attribute they should be able to update via API. | jessib | |
2013-01-29 | Allow PUT API to update user. | jessib | |
2012-12-11 | make sure can login twice | Azul | |
2012-12-08 | serve api version 1 in /1/ | Azul | |
Just a very simple start for now. Do we want to use the api for the secure remote password auth from js? |