Relevant information: I’m running DreamFactory version 1.9.0, and the admin2 version is 1.0.6 (I just ran a composer update before posing this). I used a Bitnami installer on an AWS EC2 server.
I have a role called “Product managers” set up with a few users, and I have an app set up with the “Supply a URL to the application” option selected. The application is actually on the same server (So, dreamfactory is at server.com, and the application is at server.com/application/index.html, and it is accessible manually, I’ve checked.) but obviously isn’t stored in the dreamfactory app storage. This app is set up so that it’s the default for the product managers group, since my intent was that when a product manager logs in through the dreamfactory admin console, it automatically shows them the app.
(That also isn’t working, it’s just showing the launchpad instead of the app. If that’s the intended functionality though, I would love to know if I can redirect users of a particular role to the app automatically when they log in. But that’s not the main issue here.)
Here’s the problem, when logging in the first time with a product manager account, the log in is successful and I’m shown the launchpad. But if I click F5 and refresh the page, or navigate away and back to a dreamfactory page, I just get a blank white screen. I looked at the chrome error console, and it seems like the admin2 code is hanging up when it tries to do either the first or second call to /rest/system/config.
Here’s a screenshot of the trace from the chrome console. I know it’s from the obfuscated version of admin2’s app.js code, but I hope it helps:
[This image is no longer available]
Here’s a screenshot of the network log from chrome too:
[This image is no longer available]
Oh, and in order to allow me to log in to the DreamFactory console again, I have to use the developer console in chrome to delete the ‘CurrentUserObj’ cookie that stores the json of user data. After I do that, once I refresh it loads the login screen again. It may fix itself eventually if the check for whether or not the session is expired happens within the one of the files loaded in the network log before that error happens, but if that check comes after the issue I’m encountering, then presumably it can’t be fixed unless you delete that cookie somehow.