After further inspection the header was not added by Apache Isis itself, issue resolved. Sorry for the wrong alert!
On Thu, Mar 16, 2017 at 8:06 PM, Dan Haywood <[email protected]> wrote: > 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 > > >
