How do I tie all terminal logins in Cache

Question

Question

Jon Astle · Sep 15, 2017

Hi I am trying to tie all terminal logins in Cache so that rather than the user being presented with the Cache login and password the user is presented with my custom login page.

I can do this via a generic user so that once the generic user logs in they are presented with my Cache login page however is there a way to do this so that I can bypass the below login page and go straight to my login?

Node: myserver, Instance: CACHE

Username:
Password:

Thanks in advance

Jon

Discussion (5)2

Log in or sign up to continue

Robert Cemper · Sep 15, 2017

if you disable authentication for Username / PW you always come in as "UnknownUser"

in Mgmt Portal go to System > Security Management > Users > Edit User for "UnknownUser"

and set Startup Tag^Routine: ^%zmyLOGIN
and then do your own authetication.

if you intend to go to Prorammer Mode you just have to call "do ^%PMODE" at the end.
otherwise the terminal closes.

2 0

score 0 · Answer 1 · 2017-09-15T08:42:44-04:00

John, you don't mention it explicitly, but it seems likely that your Cache is running on Windows, and you have enabled the %Service_Telnet service so that your users connect to Cache from a telnet client (which could be Cache Terminal).

In that case, [@Robert.Cemper]'s answer to this post should help you. And if it does, please credit him by setting the checkmark / tick / hook alongside it.

score 1 · Answer 2 · 2017-09-15T09:04:00-04:00

You could also take a look at the ZWELCOME routine and after going through your custom login make use of the one-argument form of $SYSTEM.Security.Login.

score 0 · Answer 3 · 2017-09-15T09:09:51-04:00

You unmark "password" and mark "not autheticate" of service "%Service_Console" and each user your configure namespace and routine default of authenticate.

way of portal:
system -> system manager -> services

Have you tried that?

score 1 · Answer 4 · 2017-09-15T09:41:47-04:00

Another method to consider is Delegated Authentication (http://localhost:57775/csp/docbook/DocBook.UI.Page.cls?KEY=GCAS_delegated). The benefit here is your custom authentication code gets run BEFORE the user is granted any kind of access to the system. The issue with relying on the routine started as soon as the login is that the user has already "breached the walls" and is in the system (and consuming a license) before you authenticate them. If your code fails for any reason or if there is a hole that allows them to break out of the code then they will likely have complete access to at least that namespace.

With Delegated Authentication you are hooking your custom code into the authentication flow of Cache. If there is any failure of code in this process the user gets "Access Denied".

One limitation is that you are only allowed a limited amount of code (2000 or 4000 commands if memory serves) to complete you authentication. After that delays are inserted into the process.

Hope that helps.