New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 612937 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Jun 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Feature



Sign in to add a comment

Option for Persistent Web Authentication in Kiosk Mode

Reported by ddellaro...@flourbluffschools.org, May 18 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Platform: 7978.74.0 (Official Build) stable-channel kip

Steps to reproduce the problem:
Not really a problem, just a requested option:
1. Enable Public Session Kiosk in Mgmt Console
2. Start public session on Chromebook
3. Log into any web account with username & password
4. Exit & restart the public session
5. User must re-login at the website

What is the expected behavior?
We would like the option to allow particular types of web authentication for specific websites to persist from public session to public session.

What went wrong?
Everything is working as intended. This is a request for added management options for public kiosk-mode sessions.

Did this work before? No 

Chrome version: <Copy from: 'about:version'>  Channel: stable
OS Version: 50.0.2661.103 (Official Build) (64-bit) Rev 0
Flash Version: 21.0.0.242-r1

If possible, it would be preferred to be able to specify which authentication methods to persist for which sites (signed cookies, tokens, etc.).
 
Labels: -Type-Bug Type-Feature
Owner: dskaram@chromium.org
Status: Assigned (was: Unconfirmed)
Please evaluate and prioritize.
Cc: dskaram@chromium.org
Owner: vidster@chromium.org
To be clear, this is for public sessions, not for kiosk mode right? Usually for such use cases, we recommend users are logged in so that their state persists throughout sessions and is also synced across devices. 

It would be useful for us to know why you settled on kiosk mode for these cases instead of logged in users.


Assigning to Vidya in either case.
Status: WontFix (was: Assigned)
Agree, this seems to be a logged in user - use case.

We likely will not address this.



Pardon for my late reply. Let me describe the issue, and maybe you can
suggest a better way to go about it.

At our Early Childhood campus, We'd like to deploy Chromebooks in a lab
setting, but don't want the kids to have their own Google accounts at that
age. A single lab account is problematic for various reasons, so kiosk mode
seemed like the best choice.

For one educational site we use, https://jr.brainpop.com/, we have a
single, campus-wide login credential. On our Windows machines the login
session persists through computer restarts, but not on Chromebooks in kiosk
mode. Four- and five-year-olds can't quickly and reliably log themselves
in, nor do we want to give the password to students in the first place.

Is there a better option that we haven't considered?

Thank you,

*Daniel DellaRocco*
District Technologist
Flour Bluff ISD
(361) 694-9134
ddellarocco@flourbluffschools.net
Have you considered building a simple app with a webview pointing to that page along with a small script that simply injects those credentials and forces login?

An alternative is using simple auth via a 3rd party Identity Provider like Clever (with their new badges product - https://clever.com/products/badges) where students can login easily to the Chromebook and then you can have more elaborate identification and authentication.

Sign in to add a comment