You could test that theory by switching off shiro... in the AppManifest, change "shiro" to "bypass", and any user/password should work...
On Thu, 16 Mar 2017 at 12:46 Martin Grigorov <[email protected]> wrote: > Hi, > > On Mar 16, 2017 1:02 PM, "Martin Hesse" <[email protected]> wrote: > > Hi, > > I am currently using Apache Isis 1.13.2 and I have a problem when uploading > a Blob. > > When the upload is complete the dialog does not close and the redirect does > not happen (no reload of the entity). > > I suspect this is due to the "X-Frame-Options" header in the ajax response > of the upload call. This is what I see in my browser console (Chrome > 56.0.2924.87). > > Refused to display ' > http://localhost:8080/wicket/entity/domainapp.dom.xxx.ZZZ:1?4 > …=true&wicket-ajax-baseurl=entity%2Fdomainapp.dom.xxx.ZZZ%3A1' > in a frame because it set 'X-Frame-Options' to 'DENY'. > > > Yes. This looks like the reason. > I guess Apache Shiro sets this header. > See how to change it to "SAMEORIGIN". > I have no experience with Shiro > > > Wicket.Ajax: Cannot read Ajax response for multipart form submit: > SecurityError: Blocked a frame with origin "http://localhost:8080"; from > accessing a cross-origin frame. > error @ wicket-ajax-jquery-ver-1473736326896.js:234 > > Wicket.Ajax: Wicket.Ajax.Call.failure: Error while parsing response: No > XML response in the IFrame document > error @ wicket-ajax-jquery-ver-1473736326896.js:234 > > > Is there an easy fix for this? If possible, not upgrading to 1.14.0 for > various reasons.... > > Thanks and regards, > Martin >
