$Sir Login - Revision history

Alex: /* Syntax terms */

2018-05-30T06:14:47Z

Syntax terms

← Older revision		Revision as of 06:14, 30 May 2018
Line 39:		Line 39:

	<tr><th>userid</th>		<tr><th>userid</th>
	<td>The user ID for which to attempt a login. This argument is required and must be non-null. At ~~least for 3270 users~~, all <var class="product">Model 204</var> user IDs must be all uppercase, so you might need to call <var>$UPCASE</var> to translate this argument to uppercase. </td></tr>		<td>The user ID for which to attempt a login. This argument is required and must be non-null. At most sites, all <var class="product">Model 204</var> user IDs must be all uppercase, so you might need to call <var>$UPCASE</var> to translate this argument to uppercase. </td></tr>

	<tr><th>accountid</th>		<tr><th>accountid</th>

JAL: misc formatting

2018-04-09T16:38:59Z

misc formatting

Show changes

JDamon: Added a second exception that allows the use of $Sir_Login; VTLAPSY

2018-03-29T22:47:10Z

Added a second exception that allows the use of $Sir_Login; VTLAPSY

← Older revision		Revision as of 22:47, 29 March 2018
Line 3:		Line 3:

	==Overview==		==Overview==
	<var>$Sir_Login</var> is a function that can be used to do user logins ~~in <var class="product">Janus Web Server</var> and <var class="product">Janus Sockets</var> applications~~. ~~Besides the ability to do user logins, it~~ is an unusual $function in several respects:		<var>$Sir_Login</var> is a $function that can be used to perform user logins. It is an unusual $function in several respects:

	<ul>		<ul>
	<li>It can only be ~~run~~ during <var class="product">Janus Web Server</var> or <var class="product">Janus Sockets</var> <var>[[NEWSESCMD]]</var> processing. Any attempt to use <var>$Sir_Login</var> outside ~~this~~ will result in request cancellation.		<li>It can only be used during:
			<ol>
			<li><var class="product">Janus Web Server</var> or <var class="product">Janus Sockets</var> <var>[[NEWSESCMD]]</var> processing
			<li> <var>[[VTLAPSY parameter\|VTLAPSY]]</VAR> logons from IODEV=7 threads
			</ol>
			Any attempt to use <var>$Sir_Login</var> outside of these two instances will result in request cancellation.
	<li>It can only be invoked by a non-logged in user. Once a user is logged in, a <var>$Sir_Login</var> call will result in request cancellation		<li>It can only be invoked by a non-logged in user. Once a user is logged in, a <var>$Sir_Login</var> call will result in request cancellation
	<li>While free to all <var class="product">Janus Web Server</var> and <var class="product">Janus Sockets</var> customers, it is implemented as a pseudo-product that requires its own authorization. This is because some sites might view the mere presence of <var>$Sir_Login</var> as a security risk so would not want		<li>While free to all <var class="product">Janus Web Server</var> and <var class="product">Janus Sockets</var> customers, it is implemented as a pseudo-product that requires its own authorization. This is because some sites might view the mere presence of <var>$Sir_Login</var> as a security risk so would not want

JDamon: Undo revision 114623 by JDamon (talk)

2018-03-29T22:23:04Z

Undo revision 114623 by JDamon (talk)

← Older revision		Revision as of 22:23, 29 March 2018
Line 6:		Line 6:

	<ul>		<ul>
			<li>It can only be run during <var class="product">Janus Web Server</var> or <var class="product">Janus Sockets</var> <var>[[NEWSESCMD]]</var> processing. Any attempt to use <var>$Sir_Login</var> outside this will result in request cancellation.
	<li>It can only be invoked by a non-logged in user. Once a user is logged in, a <var>$Sir_Login</var> call will result in request cancellation		<li>It can only be invoked by a non-logged in user. Once a user is logged in, a <var>$Sir_Login</var> call will result in request cancellation
	<li>While free to all <var class="product">Janus Web Server</var> and <var class="product">Janus Sockets</var> customers, it is implemented as a pseudo-product that requires its own authorization. This is because some sites might view the mere presence of <var>$Sir_Login</var> as a security risk so would not want		<li>While free to all <var class="product">Janus Web Server</var> and <var class="product">Janus Sockets</var> customers, it is implemented as a pseudo-product that requires its own authorization. This is because some sites might view the mere presence of <var>$Sir_Login</var> as a security risk so would not want

JDamon: Removed the restriction saying Sir_Logon can only be used by Janus Web or Janus Sockets

2018-03-29T19:56:20Z

Removed the restriction saying Sir_Logon can only be used by Janus Web or Janus Sockets

← Older revision		Revision as of 19:56, 29 March 2018
Line 6:		Line 6:

	<ul>		<ul>
	<li>It can only be run during <var class="product">Janus Web Server</var> or <var class="product">Janus Sockets</var> <var>[[NEWSESCMD]]</var> processing. Any attempt to use <var>$Sir_Login</var> outside this will result in request cancellation.
	<li>It can only be invoked by a non-logged in user. Once a user is logged in, a <var>$Sir_Login</var> call will result in request cancellation		<li>It can only be invoked by a non-logged in user. Once a user is logged in, a <var>$Sir_Login</var> call will result in request cancellation
	<li>While free to all <var class="product">Janus Web Server</var> and <var class="product">Janus Sockets</var> customers, it is implemented as a pseudo-product that requires its own authorization. This is because some sites might view the mere presence of <var>$Sir_Login</var> as a security risk so would not want		<li>While free to all <var class="product">Janus Web Server</var> and <var class="product">Janus Sockets</var> customers, it is implemented as a pseudo-product that requires its own authorization. This is because some sites might view the mere presence of <var>$Sir_Login</var> as a security risk so would not want

JAL: misc cleanup

2017-10-09T22:27:48Z

misc cleanup

Show changes

JDamon: Reworded the requirements for the 3rd (password) argument regarding case, special characters and embedded blanks.

2017-10-03T17:29:40Z

Reworded the requirements for the 3rd (password) argument regarding case, special characters and embedded blanks.

← Older revision		Revision as of 17:29, 3 October 2017
Line 27:		Line 27:
	<li>The second argument is the account ID to be used for a successful login. This argument is optional and, if not specified, the account ID is set to the same value as the userid. Again, it may be appropriate in your environment to call <var>$UPCASE</var> to translate this argument to uppercase.</li>		<li>The second argument is the account ID to be used for a successful login. This argument is optional and, if not specified, the account ID is set to the same value as the userid. Again, it may be appropriate in your environment to call <var>$UPCASE</var> to translate this argument to uppercase.</li>

	<li>The third argument is the password to be used for user authentication. This is an optional argument; if it is not specified or null, a trusted login is performed: the userid is verified as a valid userid, and if it is valid, the user is logged in without a password check. Obviously, not specifying this argument or specifying it as null should only be done when the application can be certain that the end-user is authorized to access the userid.		<li>The third argument is the password to be used for user authentication. This is an optional argument; if it is not specified or null, a trusted login is performed: the userid is verified as a valid userid, and if it is valid, the user is logged in without a password check. Obviously, not specifying this argument or specifying it as null should only be done when the application can be certain that the end-user is authorized to access the userid. If [[CUSTOM_parameter#Using_CUSTOM=(11)\|CUSTOM=11]] (allow mixed-case passwords) is <b>not</b> set, you will need to call <var>$UpCase</var> to translate this argument to uppercase characters. No automatic case translation is performed on this argument.</li>

	<p>		<p>
	Model 204 version 7.6 and earlier: Passwords can be up to 8 characters long. <br />		Model 204 version 7.6 and earlier: Passwords can be up to 8 characters long. <br />
	Model 204 version 7.7 and later: Passwords can be up to 127 characters long. ~~</p>~~		Model 204 version 7.7 and later: Passwords can be up to 127 characters long and can contain special characters and embedded blanks. Leading and trailing blanks, however, are stripped.</p>

	~~At least for 3270 users~~, ~~all <var class="product">Model 204</var> user passwords must be all uppercase~~, ~~so you might need to call <var>$UpCase</var> to translate this argument to uppercase. Or use [[CUSTOM_parameter#Using_CUSTOM=(11)\|CUSTOM=(11)]] to allow lowercase characters~~.</li>

	<li>The fourth argument is a new password for the userid. This is an optional argument, and if it is not specified or null, no new password is set on a successful login. If the third argument is null, this argument is ignored. If you want to ensure that the <var class="product">Model 204</var> user password is all uppercase, you might need to call <var>$UpCase</var> to translate this argument to uppercase.		<li>The fourth argument is a new password for the userid. This is an optional argument, and if it is not specified or null, no new password is set on a successful login. If the third argument is null, this argument is ignored. If you want to ensure that the <var class="product">Model 204</var> user password is all uppercase, you might need to call <var>$UpCase</var> to translate this argument to uppercase.

ELowell: /* Syntax */

2016-03-07T17:22:34Z

Syntax

← Older revision		Revision as of 17:22, 7 March 2016
Line 23:		Line 23:

	<ul>		<ul>
	<li>The first argument is the userid for which to attempt a login. This argument is required and must be non-null. At least for 3270 users, all <var class="product">Model 204</var> user IDs must be all uppercase, so you ~~may~~ need to call <var>$UPCASE</var> to translate this argument to uppercase.		<li>The first argument is the userid for which to attempt a login. This argument is required and must be non-null. At least for 3270 users, all <var class="product">Model 204</var> user IDs must be all uppercase, so you might need to call <var>$UPCASE</var> to translate this argument to uppercase.</li>

	<li>The second argument is the account ID to be used for a successful login. This argument is optional and, if not specified, the account ID is set to the same value as the userid. Again, it may be appropriate in your environment to call <var>$UPCASE</var> to		<li>The second argument is the account ID to be used for a successful login. This argument is optional and, if not specified, the account ID is set to the same value as the userid. Again, it may be appropriate in your environment to call <var>$UPCASE</var> to translate this argument to uppercase.</li>
	translate this argument to uppercase.

	<li>The third argument is the password to be used for user authentication. This is an optional argument; if it is not specified or null, a trusted login is performed: the userid is verified as a valid userid, and if it is valid, the user is logged in without a password check. Obviously, not specifying this argument or specifying it as null should only be done when the application can be certain that the end-user is authorized to access the userid.		<li>The third argument is the password to be used for user authentication. This is an optional argument; if it is not specified or null, a trusted login is performed: the userid is verified as a valid userid, and if it is valid, the user is logged in without a password check. Obviously, not specifying this argument or specifying it as null should only be done when the application can be certain that the end-user is authorized to access the userid.
	<p>		<p>
	Model 204 version 7.6 and earlier: Passwords can be up to 8 ~~bytes in length~~. <br />		Model 204 version 7.6 and earlier: Passwords can be up to 8 characters long. <br />
	Model 204 version 7.7 and later: Passwords can be up to 127 ~~bytes in length~~. </p>		Model 204 version 7.7 and later: Passwords can be up to 127 characters long. </p>

	At least for 3270 users~~, unless you have specified [[CUSTOM_parameter#Using_CUSTOM=(11)\|CUSTOM=(11)]]~~, all <var class="product">Model 204</var> user passwords must be all uppercase, so you might need to call <var>$UpCase</var> to translate this argument to uppercase.		At least for 3270 users, all <var class="product">Model 204</var> user passwords must be all uppercase, so you might need to call <var>$UpCase</var> to translate this argument to uppercase. Or use [[CUSTOM_parameter#Using_CUSTOM=(11)\|CUSTOM=(11)]] to allow lowercase characters.</li>

	<li>The fourth argument is a new password for the userid. This is an optional argument, and if it is not specified or null, no new password is set on a successful login. If the third argument is null, this argument is ignored. If you want to ensure that the <var class="product">Model 204</var> user password is all uppercase, you ~~may~~ need to call <var>$UpCase</var> to translate this argument to uppercase.		<li>The fourth argument is a new password for the userid. This is an optional argument, and if it is not specified or null, no new password is set on a successful login. If the third argument is null, this argument is ignored. If you want to ensure that the <var class="product">Model 204</var> user password is all uppercase, you might need to call <var>$UpCase</var> to translate this argument to uppercase.

			<p>
			Model 204 version 7.6 and earlier: Passwords can be up to 8 characters long. <br />
			Model 204 version 7.7 and later: Passwords can be up to 127 characters long. </p>
			</li>
	<li>The fifth argument is a blank-delimited set of option words. These options can be		<li>The fifth argument is a blank-delimited set of option words. These options can be

Line 45:		Line 49:

	<tr><th><var>NOCHECK</var></th>		<tr><th><var>NOCHECK</var></th>
	<td>Indicates that the user should be logged in without checking to see if the userid is defined in CCASTAT or the external authorizer database. A NOCHECK login is a trusted login, since for such a login the userid is not looked up anywhere so there's no password to check. NOCHECK is similar to GUEST with the exception that NOCHECK doesn't even bother to do a lookup for the user. This means a NOCHECK login is more efficient than a GUEST login, especially if an external authorizer is being used. The downside is that with a NOCHECK login, the user cannot pick up additional privileges if the userid happens to be defined in CCASTAT or the external authorizer database. Of course this downside might be considered an upside if the userids used in a particular <var>$Sir_Login</var> call are independent of userids in CCASTAT or the external authorizer database.		<td><p>Indicates that the user should be logged in without checking to see if the userid is defined in CCASTAT or the external authorizer database. A NOCHECK login is a trusted login, since for such a login the userid is not looked up anywhere so there's no password to check.</p>
			<p>NOCHECK is similar to GUEST with the exception that NOCHECK doesn't even bother to do a lookup for the user. This means a NOCHECK login is more efficient than a GUEST login, especially if an external authorizer is being used. The downside is that with a NOCHECK login, the user cannot pick up additional privileges if the userid happens to be defined in CCASTAT or the external authorizer database. Of course this downside might be considered an upside if the userids used in a particular <var>$Sir_Login</var> call are independent of userids in CCASTAT or the external authorizer database.</p>
	<p>		<p>
	The <var>NEWSESGUESTOK</var> parameter must be specified on the Janus port definition if the <var>NOCHECK</var> option is used with <var>$Sir_Login</var>.</p></td></tr>		The <var>NEWSESGUESTOK</var> parameter must be specified on the Janus port definition if the <var>NOCHECK</var> option is used with <var>$Sir_Login</var>.</p></td></tr>
Line 52:		Line 57:
	<td>Indicates that the userid for which the login is done can do subsequent trusted logins by simply typing <code>LOGON</code> (with no userid) on the <var class="product">Model 204</var> command line.		<td>Indicates that the userid for which the login is done can do subsequent trusted logins by simply typing <code>LOGON</code> (with no userid) on the <var class="product">Model 204</var> command line.
	<p>		<p>
	This feature is probably most useful in a development Online where end-users have access to the <var class="product">Model 204</var> command line and might		This feature is probably most useful in a development Online where end users have access to the <var class="product">Model 204</var> command line and might
	want to do a quick logon/logoff sequence to reset everything. Simply being able to type <code>LOGON</code> eliminates the need for re-entering a		want to do a quick logon/logoff sequence to reset everything. Simply being able to type <code>LOGON</code> eliminates the need for re-entering a
	password, so it makes quick logon/logoffs much simpler than it would be otherwise. And since the user already logged on to the thread once, there is no security hole in doing a subsequent trusted login. This parameter is only allowed for applications running on a TNSERV port, and like TNSERV ports, it is only available in Sirius Mods version 6.9 and later.</p></td></tr>		password, so it makes quick logon/logoffs much simpler than it would be otherwise. And since the user already logged on to the thread once, there is no security hole in doing a subsequent trusted login.</p>
			<p>This parameter is only allowed for applications running on a TNSERV port, and like TNSERV ports, it is only available in Sirius Mods version 6.9 and later.</p></td></tr>
	</table>		</table>
			</li>

	<li>The sixth argument is the $list identifier of a $list to receive any terminal messages		<li>The sixth argument is the $list identifier of a $list to receive any terminal messages
Line 63:		Line 70:
	which could:		which could:
	<ul>		<ul>
	<li>In a <var class="product">Janus Web Server</var> <var>$Sir_Login</var>, send the output to the browser or the audit trail, or simply swallow it.		<li>In a <var class="product">Janus Web Server</var> <var>$Sir_Login</var>, send the output to the browser or the audit trail, or simply swallow it.</li>

	<li>In a <var class="product">Janus Sockets</var> <var>$Sir_Login</var>, send the output to the audit trail or to one or more open sockets.		<li>In a <var class="product">Janus Sockets</var> <var>$Sir_Login</var>, send the output to the audit trail or to one or more open sockets.</li>

	<li>In either a <var class="product">Janus Web Server</var> or a <var class="product">Janus Sockets</var> <var>$Sir_Login</var>, capture terminal output to a $list via <var>[[$List_Capture]]</var>.		<li>In either a <var class="product">Janus Web Server</var> or a <var class="product">Janus Sockets</var> <var>$Sir_Login</var>, capture terminal output to a $list via <var>[[$List_Capture]]</var>.

	If <var>$Sir_Login</var> is invoked with an output [[$lists\|$list]], the X'06' bits of the <var class="product">Model 204</var> <var>[[MSGCTL parameter\|MSGCTL]]</var> user parameter are automatically cleared, then restored upon completion of <var>$Sir_Login</var> processing. This ensures that logon messages are sent to the "terminal" and so the output $list, no matter what the current <var>MSGCTL</var> setting is. APSY subsystems that suppress messages do so by setting one or both of the <var>MSGCTL</var> X'06' bits. <var>$List_Capture</var> does not affect the <var>MSGCTL</var> setting.		If <var>$Sir_Login</var> is invoked with an output [[$lists\|$list]], the X'06' bits of the <var class="product">Model 204</var> <var>[[MSGCTL parameter\|MSGCTL]]</var> user parameter are automatically cleared, then restored upon completion of <var>$Sir_Login</var> processing. This ensures that logon messages are sent to the "terminal" and so the output $list, no matter what the current <var>MSGCTL</var> setting is. APSY subsystems that suppress messages do so by setting one or both of the <var>MSGCTL</var> X'06' bits. <var>$List_Capture</var> does not affect the <var>MSGCTL</var> setting.</li>
	</ul>		</ul></li>
	</ul>		</ul>

ELowell at 23:38, 4 March 2016

2016-03-04T23:38:02Z

← Older revision		Revision as of 23:38, 4 March 2016
Line 28:		Line 28:
	translate this argument to uppercase.		translate this argument to uppercase.

	<li>The third argument is the password to be used for user authentication. This is an optional argument; if it is not specified or null, a trusted login is performed: the userid is verified as a valid userid, and if it is valid, the user is logged in without a		<li>The third argument is the password to be used for user authentication. This is an optional argument; if it is not specified or null, a trusted login is performed: the userid is verified as a valid userid, and if it is valid, the user is logged in without a password check. Obviously, not specifying this argument or specifying it as null should only be done when the application can be certain that the end-user is authorized to access the userid.
	password check. Obviously, not specifying this argument or specifying it as null should only be done when the application can be certain that the end-user is authorized to access the userid. At least for 3270 users, all <var class="product">Model 204</var> user passwords must be all uppercase, so you ~~may~~ need to call <var>$UpCase</var> to translate this argument to uppercase.		<p>
			Model 204 version 7.6 and earlier: Passwords can be up to 8 bytes in length. <br />
			Model 204 version 7.7 and later: Passwords can be up to 127 bytes in length. </p>

			At least for 3270 users, unless you have specified [[CUSTOM_parameter#Using_CUSTOM=(11)\|CUSTOM=(11)]], all <var class="product">Model 204</var> user passwords must be all uppercase, so you might need to call <var>$UpCase</var> to translate this argument to uppercase.

	<li>The fourth argument is a new password for the userid. This is an optional argument, and if it is not specified or null, no new password is set on a successful login. If the third argument is null, this argument is ignored. If you want to ensure that the <var class="product">Model 204</var> user password is all uppercase, you may need to call <var>$UpCase</var> to translate this argument to uppercase.		<li>The fourth argument is a new password for the userid. This is an optional argument, and if it is not specified or null, no new password is set on a successful login. If the third argument is null, this argument is ignored. If you want to ensure that the <var class="product">Model 204</var> user password is all uppercase, you may need to call <var>$UpCase</var> to translate this argument to uppercase.

ELowell at 23:11, 4 March 2016

2016-03-04T23:11:12Z

← Older revision		Revision as of 23:11, 4 March 2016
Line 126:		Line 126:
	</p>		</p>

	An even more sophisticated <var>NEWSESCMD</var> application could itself maintain the USERS file that contains ~~say~~ a common name, MD5 certificate hash and a <var class="product">Model 204</var> userid associated with the certificate. When a certificate is received, the common name and MD5 hash can be looked up in the database:		An even more sophisticated <var>NEWSESCMD</var> application could itself maintain the USERS file that contains, for example, a common name, MD5 certificate hash and a <var class="product">Model 204</var> userid associated with the certificate. When a certificate is received, the common name and MD5 hash can be looked up in the database:

	<p class="code"> %CNAME = $WEB_CERT_INFO('CNAME')		<p class="code"> %CNAME = $WEB_CERT_INFO('CNAME')
Line 249:		Line 249:
	</p>		</p>

	The combination of <var>$Sir_Login</var> and <var>NEWSESCMD</var> processing provides a very flexible set of facilities that allows a site to tailor <var class="product">Janus Web Server</var> and <var class="product">Janus Sockets</var> user authentication as needed. With that flexibility comes the responsibility to ensure that the chosen user authentication approach is, indeed, secure. Toward this end, it is strongly recommended that <var>NEWSESCMD</var> code be examined by as many eyes as is reasonable, and that ~~Sirius~~ Software be contacted to review <var>NEWSESCMD</var> code.		The combination of <var>$Sir_Login</var> and <var>NEWSESCMD</var> processing provides a very flexible set of facilities that allows a site to tailor <var class="product">Janus Web Server</var> and <var class="product">Janus Sockets</var> user authentication as needed. With that flexibility comes the responsibility to ensure that the chosen user authentication approach is, indeed, secure. Toward this end, it is strongly recommended that <var>NEWSESCMD</var> code be examined by as many eyes as is reasonable, and that Rocket Software be contacted to review <var>NEWSESCMD</var> code.

	==Sample APSY==		==Sample APSY==

	A sample APSY subsystem that can be used with the <var>NEWSESCMD</var> subcommand is provided by ~~Sirius~~ Software (it is the same sample subsystem provided for use with the <var>[[VTLAPSY parameter\|VTLAPSY]]</var> parameter for IODEV7 users). The code is in the SIRIUS file, beginning with <var class="product">[[ULSPF\|UL/SPF]]</var> Version 7.7. Programs are VTLN.LOGIN and VTLN.ERROR, and the comments in VTLN.LOGIN explain how to customize the programs for the local environment.		A sample APSY subsystem that can be used with the <var>NEWSESCMD</var> subcommand is provided by Rocket Software (it is the same sample subsystem provided for use with the <var>[[VTLAPSY parameter\|VTLAPSY]]</var> parameter for IODEV7 users). The code is in the SIRIUS file, beginning with <var class="product">[[ULSPF\|UL/SPF]]</var> Version 7.7. Programs are VTLN.LOGIN and VTLN.ERROR, and the comments in VTLN.LOGIN explain how to customize the programs for the local environment.

	[[Category:Janus Web Server $functions\|$Sir_Login]]		[[Category:Janus Web Server $functions\|$Sir_Login]]