I've researched the forum quite extensively but have not quite found the answer for how to automatically log in a User (and refresh the client accordingly).
Here is the workflow I am attempting to achieve:
As a work-around we have dealt with this by associating the "order" to the Session of the anonymous user. Our default homepage is currently a microflow that will check if an "order" is associated to the current session and, if so, then it will re-direct the proper page. This works, but is not ideal because we are forcing the User to create an account and then we immediately prompt them to log in to their account (which can be burdensome).
One of the issues was with step 3 (above) was that the Account does not exist within the database until the end of the microflow, but we want to achieve the committing of the Account as well as the automatic login within this one microflow. A solution that I found was to use a java action to end the database transaction (so the Account is committed before the automatic login is attempted, otherwise the account will not be found). I've used this simple line of code to achieve this:
I've created a java action, AutoLogin.java, that will complete this automatic login that takes in two parameters: the Username (String) of the newly created account and the current Session (MxObject). The java action returns a boolean -- true if the login was successful and false otherwise. In this java action I have used this line of code to update the session as the new User:
ISession updatedSession = Core.initializeSession(Core.getUser(this.getContext(), Username), CurrentSession.getSessionId());
I have debugged this java and it does seem to work -- it carries over the data from the previous session to a new, logged in session for the User. Here's what this looks like in a microflow: example microflow in modelshare
The first action is to Commit the Account The Second Action is the java action that ends the transaction (forces the database commit) and then logs in the user with the above code The third action shows the PurchasePage (the next step in the workflow) The fourth (final) action refreshes the "order" (which is the caller of the page)
The next page has "order" as the caller and pieces of the Account data over association (i.e. billing address, name...). I found that the java action was creating the session, but the data was unaccessable for the account when I went to the next page unless I refreshed the page (I'm using Google Chrome if this is at all relevant) upon which everything appears PERFECTLY -- the account information is there and I can proceed with the workflow as I would have hoped.
Adding the refresh of the "order" made it even a little better -- I was now able to see all of the account information to be filled out when I was on the next page but there is one issue: There is a button at the bottom (Purchase) which I have restricted access based on User Roles (only Users can call the Purchase microflow). This button is NOT visible which leads me to believe that I need to, in some way, refresh the security roles for the application (or something of the sort). When I refresh the page (again, Google Chrome) the Purchase button appears and again, everything works exactly as I would have hoped.
I've done some research into refreshing user roles and have, in particular, stumbled upon this post: related forum post
But it seems, to me, that this is logging out the current session and then creating a new session. I see the bit about adding session cookies and it is my suspicion that that is the part I am missing. I am looking for a way to take the current anonymous session and then essentially "change" it into a logged in session for the newly created User (with all of the security rights associated).
I am also curious why refreshing the browser window provides the desired security refresh.
Any help or insight is greatly appreciated.
Thanks in advance,
You seem to have everything figured out yourself already :).
I don't think you can get around using a redirect to your own RequestHandler that will set the correct session cookie in the client's browser. I would also expect that you need to create a new session (with a new session id) in any case, I think that is already happening in your current setup when you force a refresh in your browser.
If you look at the existing RequestHandler from the DeepLink app store module this should give you enough hints on how to do this (together with Herbert's post in the thread you linked to).