[Mifos-issues] [JIRA] (MIFOSX-899) Community App triggers authentication when running pentaho reports for the first time

[Lance Good (JIRA)]

Title: Message Title

Lance Good edited a comment on MIFOSX-899   Re: Community App triggers authentication when running pentaho reports for the first time Since I did a little research to understand this issue, I thought it might be worth trying to explain some of the details here for posterity.  The community app is using basic access authentication.   [ Here's a wikipedia page ] (http://en.wikipedia.org/wiki/Basic_access_authentication) on the topic.  The gist is that requests are sent with the username and password encoded with base64.  Note, that is *encoded* and not encrypted.  It's pretty trivial to decode them.  The assumption is that requests will only be sent over https. So how does the header get set that contains the encoded username and password?  The community app appears to be  completely AJAX based.  This means that it loads a single base web page and then loads all subsequent content via AJAX.  The authentication details are therefore filled in the first time the base page is accessed and then stored in the _javascript_ state of the page.  This is why if you refresh the page or open the same URL in a new tab, you are forced to login again.  The authentication details are not stored in a cookie or local storage or anything like that.  The _javascript_ in the application has to add the authentication header to every request.  This is why when the pentaho form url is set on an iframe, the iframe does not include the authentication.  It's a plain request for a full HTML page where the _javascript_ cannot set a header.  That's why the browser authentication dialog pops up. Note that the browser does its own caching of basic access authentication if you login with the default login dialog.  So once you login using the browser dialog, you will continue to be logged in basically until you close the browse.  The exact details of how these authentication details are cached depends on the browser.  There also doesn't appear to be a consistent programmatic way to set the authentication details in the browser cache, and it's not clear that you'd want to anyway. It is also very unlikely that you'll be able to set a header on the iframe's HTML request.  There is specific support for setting the username and password on a single request via something like https://username:password@hostname.  Given that the credentials are stored in _javascript_ in (at best) an encoded form, we definitely have access to the username and password from _javascript_.   This is definitely a risky move for a banking app since the password will be stored right in the URL of any server logs.  There is also an additional problem that some browsers (in particular, IE8 and below) don't even support this URL format.  See  [ here ] (https://support.microsoft.com/en-us/kb/834489), for example.   So I think this solution is pretty much a nonstarter. There is another solution that I have working for this case.  I was able to make an AJAX request for the form HTML from RunReportsController.js.  I then set the src URL on the iframe to a data URL, something like src="" /> Other potential options would be to change the server somehow to return JSON instead of HTML or to change the entire app to a security model other than basic authentication.  I'm guessing both of those aren't really options though. Does someone with more background on the community app have insight into which of these solutions would be acceptable?  Or whether the current behavior is better than these alternatives? Add Comment   This message was sent by Atlassian JIRA (v6.5-OD-05-041#65001-sha1:e07c9f6)

------------------------------------------------------------------------------

_______________________________________________
Mifos-issues mailing list
Mifos-issues@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mifos-issues