Samigo uses POST without Redirect Pattern in Several Places
Description
Attachments
is related to
relates to
Activity
Matthew Jones March 19, 2016 at 10:44 AM
I'm going to close this and open a new jira for the resolution.
Matthew Jones January 12, 2016 at 10:17 AM
From Core Call: I believe Earle had some ideas for using navigation outcomes to determine whether or not to run this (Maybe something like https://docs.oracle.com/javaee/5/tutorial/doc/bnaxf.html). I'm not sure if this will be easy to do or not. If it's not going to be easy, either just revert or revert and just apply the original minimal patch for now.
Matthew Jones January 11, 2016 at 8:41 PM
Well I just wanted your advice on reverting it, since it breaks the errors messages. We could selectively revert some pages but I couldn't easily seem to identify those, only reverting this fixed it.
The problem is that with this redirect pattern, the JSF error messages weren't captured and displayed as part of the redirect. ;(
I'd like to move the error messages to something like the PA System or using the growl style popups that provides the errors for the user entered HTML so we get them out of this context entirely and they can all be displayed in a nice popup but I don't feel like I'll have time to do this before 11.
Charles R Severance January 11, 2016 at 8:36 PM
Feel free to fix as you see fit.
Matthew Jones October 23, 2015 at 3:50 PM
I feel like this entire change is going to need to get backed out or a much more cut back version of it put in. The pages can't run the redirect if there's messages in the context that need to be persisted.
I believe the logic that previously persisted them was when it called req.sendRedirect in the SamigoJsfTool. It would set a attribute of sakai.redirect on the request and save the messages in the context between redirects. With this code in here it's not calling that and RequestFilter isn't properly running the workflow.
There are a number of places where Samigo is returning markup as a result of a POST operation instead of processing the POST with no markup and doing a redirect. Luckily JSF generally solves this with a configuration change - you simply add <redirect/> to the <navigation-case> entries and JSF handles everything.
The easiest way to reproduce this is to open Samigo in a frame by itself and then switch among the top four options. You can watch the dev console. You will see POSTs and the URL will reflect the page you are coming from in the navigation - not the page that you are seeing. Also when you use the back button you get the "repost form data" dialog.
As we move to frameless approaches the details of tool url will start to be more obvious in the location bar, and users will start to use the back button as well as bookmark deep links into the application right from the location bar. So we need to have these URLs looking nicer.
I have done some initial testing adding the <redirect/> rule to the four navigation rules for the top navigation menu and things work great.
src/webapp/WEB-INF/faces-config.xml
My instinct would be to just add <redirect/> to every URL that was not being used as AJAX or as some kind of web service. Since the logic only triggers on POST, I can't imagine any harm - but of course it would be good to test the code after making the change.