Guest Login, Permissions and Kiosk Dashboards

phildunlap

https://superuser.com/questions/719875/google-chrome-always-says-google-chrome-was-not-shut-down-properly
https://superuser.com/questions/237608/how-to-hide-chrome-warning-after-crash

TLDR
It looks like you can modify "%UserProfile%\AppData\Local\Google\Chrome\User Data\Default\Preferences" (Windows, probably something similar in ~/ on Linux. Edit: people in the second link have ~/.config/google-chrome/Default/Preferences) for "exit_type":"Crashed" --> "exit_type":"Normal"

I tried it, it works! Chrome writes the exit type to Crashed when it starts.

henryblu

Awesome - managed to make it work this time! Thank you, all is fine now.

Jared Wiltshire

@henryblu That code is not pasted into a dashboards page, it is basically the skeleton for a whole custom app. You can't use it with Custom Pages / Dashboard Designer.

I can definitely look into making it easier to setup auto-login from a centralized location. I can probably add it into the UI settings page as a matter of fact and also add URL parameter options.

mihairosu

@Jared-Wiltshire We would absolutely love to be able to do any of those things. Would really make our lives a little easier.

We can think of more places we'd like to use the dashboards but where we can't simply log in locally.

Jared Wiltshire

@mihairosu There will be more options in the next UI module release, I'll update this thread with more details when I do the release.

Jared Wiltshire

@mihairosu @henryblu
I've added more options for logging in automatically to the latest UI module (v3.1.8).

There are now three options for supplying the auto-login credentials (in order of precedence)

Url parameters
Local storage/cookies (this used to be the only option)
From the UI settings which are stored in the REST API JSON store

Important warning
Never use admin credentials for auto-login, always use a view-only/restricted user. The password will be stored/and or transmitted in plain text. When using the UI settings, the credentials will be publicly accessible from the REST API!

Url parameters
You can supply auto-login credentials using the autoLoginUsername and autoLoginPassword url/query parameters.
e.g. https://mymangodomain.com/ui/home?autoLoginUsername=publicuser&autoLoginPassword=publicpassword

There is also a parameter which will store the credentials from the URL into the local storage/cookies - autoLoginStoreCredentials. This ensures that if the user navigates away and comes back to Mango the credentials are still available.
e.g. https://mymangodomain.com/ui/home?autoLoginUsername=publicuser&autoLoginPassword=publicpassword&autoLoginStoreCredentials

autoLoginDeleteCredentials can be used to delete these credentials in the event that you no longer want users to be auto-logged in.

Local storage/cookies
You can store the credentials in the browser's local storage/cookies via the "Auto-login (local)" page under "Administration", or via the url parameters as explained above. These credentials must be added on a per machine/browser basis.

UI settings / JSON store
You can store auto-login credentials for all clients on the "UI settings" page under "Administration". Any client/browser which connects to the Mango instance will use these credentials (provided they are not logged in via one of the previous methods).

mihairosu

Jared,

Thank you so much for putting all this effort into these new features!!

It looks like they work with the new UI but not the old dashboard pages, which I believe Joel warned us about.

As soon as get the chance to transfer our pages over, I'll be able to fully test these. My initial tests show they work just fine however.

I'm pretty excited about these changes.

Thanks again.

Jared Wiltshire

@mihairosu You could create a dashboard in the new UI that simply redirects to the old page. When you hit the new UI page you will be logged in then redirect.
e.g. just put this in the markup

<meta HTTP-EQUIV="REFRESH" content="0; url=/legacy_page.htm">

P.S. this isn't valid markup but it seems to work (it should go in the head). You could also just use a script tag and set window.location.

MattFox

Hi @Jared, have been trying to implement the auto login feature for the last day or so. Getting slightly annoyed with the auto login local not compatible with the admin template single page app (only just read in one of your other posts in May that it's deprecated which doesn't help me much here now that I am now up to my neck in it.)
Are you willing to provide some assistance here so I can work out how to implement the cookie type browser storage so that individual users can set an auto login if they wish to? Not so fond of the url type implementation.

Jared Wiltshire

@MattFox The latest adminTemplate should work with the autologin, what version are you using?

You will need to enter the credentials at /ui/administration/auto-login-settings but after that the adminTemplate should log you in automatically.

MattFox

Morning Jared, apologies for the late reply, Friday through Sunday seemed to move as one giant blur...
It's more the fact I'm trying to do multiple custom dashboards. These dashboards each possess their own login for separate users and display different data. There is no wish for them to be able to access the /ui backend as some of the dashboards coded are used for realtime data display on a tv for example.

However, it would be nice to be able to implement the same code for this into the custom dashboards so that users can configure an auto-login should they wish to.

Thanks again for your time

Matt

Jared Wiltshire

@mattfox said in Guest Login, Permissions and Kiosk Dashboards:

It's more the fact I'm trying to do multiple custom dashboards. These dashboards each possess their own login for separate users and display different data. There is no wish for them to be able to access the /ui backend as some of the dashboards coded are used for realtime data display on a tv for example.

The fact that you need display different data for different users should not preclude you from using /ui. You can hide menu items for different users, set permissions on data points and set user's home pages.

If you setup the main /ui app this way it will save you a lot of time maintaining separate custom applications.

@mattfox said in Guest Login, Permissions and Kiosk Dashboards:

However, it would be nice to be able to implement the same code for this into the custom dashboards so that users can configure an auto-login should they wish to.

If you still want to make separate applications you can copy the autoLoginSettings component from the ui/components folder into your custom app. You will need to register it as part of the application in app.js. This component just displays a username/password form and saves the credentials to local storage/cookies.

The actual auto-login code is in the User service and is called from the bottom of app.js. You can change the prefix that it is used to store/retrieve data from local storage if needed, let me know if you do.

MattFox

@jared-wiltshire said in Guest Login, Permissions and Kiosk Dashboards:

The fact that you need display different data for different users should not preclude you from using /ui.

I wish that were the case, but I am not using angular material based components to display data in these instances and thus have had to make my own point queries to pull the data through and parse it into a format to suit the interfaces I have made.
I'll definitely take you up on that offer of changing the prefix. Chances are i'm going to need to do it at some point.

Jared Wiltshire

@mattfox said in Guest Login, Permissions and Kiosk Dashboards:

@jared-wiltshire said in Guest Login, Permissions and Kiosk Dashboards:

The fact that you need display different data for different users should not preclude you from using /ui.

I wish that were the case, but I am not using angular material based components to display data in these instances and thus have had to make my own point queries to pull the data through and parse it into a format to suit the interfaces I have made.
I'll definitely take you up on that offer of changing the prefix. Chances are i'm going to need to do it at some point.

OK fair enough then.

So if you look at ngMango/ngMangoServices.js you will see the config() block configures localStorageServiceProvider with a prefix. You just need to add that to the config block in your app.js, this will ensure the local storage for each of your apps will work independently.

MattFox

Many thanks for dealing with my selfish whims Jared, have a great afternoon. Watch this space!

MattFox

That appears to have done it! Thanks Jared!