Hello Everyone !
I have been experimenting with the Sparklr2 and Tonr2 applications. I have them deployed on two difference Tomcat instances and have been debugging the code that Ryan Heaton has written.
I have a few questions regarding the Spring XML configuration that needs to be set up to force the client application not only to be sent to the oauth/user/authorize url for authorization but also to the /oauth/authorize URL where the user actually gets an access_token and an refresh_token. In the sample applications that I am running I never see the client actually invoke the Restful web service requesting the photos from Sparklr and sending the request with the access_token in the Authorization header. I only see the "authorization" phase where the client application is sent to the accessConfirmation.jsp page and is asked to either authorize or decline access. After the client has clicked on the "Authorize" button, the client should receive an access_token and optionally a refresh_token. I should be able to take the access_token and refresh_token and persist it in the database for future client/server sessions and for creating a new token once the old token has expired or was revoked. I just don't see anywhere in the sparklr2/tonr2 demo application where the client actually makes a request using the authRestTemplate and sets the Header Authorization to contain the access_code given by the Authorization Server to the Client App.
In the application I am writing I have a requirement not only to haver users with username and password coming from a database and not hardcoded in the xml config file. I also have a requirement to persist the access_token and refresh_token on behalf of a client id.
What example can I look at to figure out how to change the Sparklr2/tonr2 xml config file to force the two step protocol ( authorization/access_code/refresh_code ) and to save the the access_code and refresh_code for the given clientId/secret_code ?
Please, I would appreciate your help on this matter. I have been studying the very interesting demo application written by Ryan Heaton but have not been able to figure out the access_token and the /oauth/authorize part yet.
Sr. Software Engineer/Tracom/Denver