summaryrefslogtreecommitdiff
path: root/users/app/controllers/v1
AgeCommit message (Collapse)Author
2014-04-08moving users: app and test filesAzul
2014-02-10Merge pull request #139 from azul/refactor/tweaks-to-messagesjessib
Refactor/tweaks to messages
2014-02-10require token in messages controllerAzul
2014-02-10require token when logging out via APIAzul
2014-02-10require token when updating user via APIAzul
2014-02-10rename authorize to require_loginAzul
authorize_admin -> require_admin also add require_token which will ensure token has been used for auth.
2014-02-10minor: move some logic from message controller into modelAzul
2014-01-09Some 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-07Some 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-31Add authentication to API, but not sure it is best way.jessib
2013-12-31Cleanup of code for messages API and cron job for 1 month payment warning. ↵jessib
Authentication still remaining piece.
2013-12-30Change structure to be more no-sql-y, rather than relational.jessib
2013-12-24Catching some corner cases & new tests.jessib
2013-12-24Add API tests and some refactoring of messages so we can get a user's ↵jessib
messages within the webapp.
2013-12-24API method to mark a user's message as read (will refactor)jessib
2013-12-24Initial start to messages API.jessib
2013-11-06use the account lifecycle from UsersController#destroyAzul
2013-09-24use token auth when accessing the api from webappAzul
One failing integration test still needs to be fixed
2013-09-18user.account shortcut to Account.new(user)Azul
2013-09-03Merge pull request #73 from azul/bugfix/3623-teardown-test-data-properlyjessib
Bugfix/3623 teardown test data properly
2013-09-03clearify usage of V1::UsersController#index for autocompleteAzul
[skip ci]
2013-09-03Account: Composition to handle User and its identitiesAzul
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-27Merge branch 'master' into billing_with_testsjessib
2013-08-21return 204 NO CONTENT on API logoutAzul
That's the only meaningful response.
2013-07-24separate signup and settings service objects for userAzul
2013-07-24removed email settings controller and viewsAzul
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-17fix account flow integration testAzul
not really sure what to do if the second step of srp auth is repeated.
2013-07-04user tests -- user update has been moved entirely to api controller, so fix ↵elijah
tests to reflect this.
2013-07-04fix user typeaheadelijah
2013-07-04users 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-09return token on successful login via apiAzul
2013-04-02send salt on Session#create without srp ephemeral AAzul
2013-02-26api for sessions fixedAzul
* now we return the user id on login * allow a destroy request for logging out * added test for api sessions controller
2013-01-31Remove 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-29A user's public_key is the only attribute they should be able to update via API.jessib
2013-01-29Allow PUT API to update user.jessib
2012-12-11make sure can login twiceAzul
2012-12-08serve 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?