Flicks FAQ: Cookieswvalue


Back to the top of the FAQ

CookieSWValue

Applies To

AuthentiX OCX Component

The CookieSWValue (cookie site-wide value) returns a value of the form <username>cryptvalue where cryptvalue is the standard MD5 (crypt) hash of the username and the user's password. Available in Version 4.6c and above.

For cookie-based installations of AuthentiX only:

With later versions of ASP.NET, the "<" and ">" delimiters are considered to form a possible XSS attack.
To avoid having to disable the framework XSS protection, Version 6.2d (10/3/06) and above allow you to set your own delimiters.
Upgrade now.
Then go to Start-Programs-Flicks Software-AuthentiX, click on Options, Cookie.
The recommended replacements are pipe (|) and ampersand (&) respectively.

The code below will have to be modified also to match your delimiters.

Use like this:
response.Cookies("AXCOOKIELOGIN") = auth.CookieSWValue("username", "password")

See the ASPocxSamples\EasyCookieLogin sub-directory of the installation directory for a working sample.

If you need to get the CurrentUserName with CookieSWValue, just get the plain-text username out of the AXCOOKIELOGIN cookie (ie the part of the value of the cookie that comes before the "<").

' the user has been validated, so we already know the u/p is ok
' try the cookie
if ("" = username) then
	currentUserText = Request.Cookies("AXCOOKIELOGIN")
	if ("" <> currentUserText) Then
		username = Right(currentUserText, Len(currentUserText) -1)
		pos = Instr(username, ">") - 1
		username = Left(username, pos)
	End if
End if

Warning (3/20/00) Site-wide cookies cannot be used with Protection by NT/AD Account. You will need to use per-directory cookies instead.
This is because Site-wide cookies (unlike per-directory cookies) uses a 1-way hash to encode the password, and so cannot be successfully compared with an NT retrieved password (since they are also 1-way encrypted!).

Confusion Alert (3/20/00) Because the cryptvalue/username is enclosed in "<" and ">" it will not show up in a simple response.write statement since the browser thinks it's a tag. This is good if you want to conceal this information from casual observers, bad if you are trying to debug.

This function is provided so that a login cookie can be set for the entire site. Unlike the CookieLoginCookieName, CookieLoginValue and CookieCurrentUserName family (where cookies are set for each protected directory), CookieSWValue is site-wide. Note that protection only applies to directories which have been set up as AuthentiX cookie-protected directories (see the Protect-by tab, and the cookie Configure button).

CookieSWValue is easier to setup.

CookieLoginValue has the advantage that a single browser can log in to different directories of a website with different username/pasword combinations on each, and not have to resubmit each username and password when navigating between the different directories. CookieLoginValue runs into problems however when there is a dynamically changing set of protected directories, or when there are a large number of separately protected directories.
If there are a large number of directories the number of corresponding cookies may exceed the number of cookies permitted by a browser (some limit this to 20).
If there is a dynamically changing set of protected directories, implementing the loginnow.asp page can be complex.

CookieSWValue allows you to easily set the password for many, many directories, that may change dynamically over time.

If cookie-timeouts are required, then be sure to set each protected directory's Cookie-timeout radio button. Note however that if you are using site-wide cookies, the timeout value in the Options/Cookie dialog overrides the timeout value for each individual directory's timeout setting.

Cookie-timeout note (2/19/04): The cookie-timeout is checked periodically, and this period is defined in the "Minutes between cache cleanup" section of this dialog. If you set the cookie-timeout to be quite low (eg 5 minutes), then make sure the "Minutes between cache cleanup" is less or lower.
(The cleanup routine checks the cookie timeout every "Minutes between cache cleanup". However this is not synchronized with when a particular cookie's timeout is begun. So if you have "Minutes between cache cleanup" set to 5, and cookie-timeout set to 2, then a cookie will timeout between 5 and 7 minutes, and on average 6 minutes.)

Notes - GetCrypt
If you are using ODBC/Advanced protection, or By COM, you will need to use GetCrypt in the AXSupport.ocx module to compare the supplied MD5 crypted password with the password in your database, like so:



declare @strMD5 varchar(100)	-- MD5 hash value
declare @oAuth int		--AXSupport Object Handle
declare @resultcode int		--result code from OA calls

-- create Object
EXEC @resultcode = sp_OACreate 'AXSUPPORT.AXSupportCtrl.1', @oAuth OUT

IF @resultcode = 0	-- if successful
BEGIN
	-- execute GetCrypt and put hash value into @strMD5
	EXEC @resultcode = sp_OAMethod @oAuth, GetCrypt, @strMD5 OUTPUT,
'test_username', 'test_password'

	-- destroy Object
	EXEC sp_OADestroy @oAuth
END	

PRINT @strMD5	-- print for debug purposes

then compare the result against the supplied password. (Please correct my SQL Stored procedure syntax). Note, the progid is "AXSUPPORT.AXSupportCtrl.1".
With Basic Authentication, the password supplied by the user will be Base64 decoded and passed to your stored procedure or COM component in clear text.
However with site-wide cookies the password has the extra security of being MD5 hashed. This cannot be decoded or decrypted and so the above technique is used:

Unlike Basic Authentication, site-wide cookie-protection uses MD5 hashing to encode the password. When it looks up the password in the database, it cannot compare it directly to the supplied password, because the supplied password is MD5 encrypted. What it does instead is MD5 encrypt the password in the database, and compare it to the supplied password to see if it matches.
This means that passwords are case sensitive, and passWorD will not match PaSSword.
If you really need case-insensitive cookie passwords, you could try using per-directory cookies, which is slightly more complex, but doesn't use MD5 hashing for the password.

See here for more examples of how to call general OCX components from languages such as Perl and SQL (the samples do not use the above functions however).

Syntax

CookieSWValue(Username, Password)

Parameters

Username
The Username collected by the login form.
Password
The Password collected by the login form.

Return Values

Returns the initial cookie value to be used when first accessing a cookie protected directory.

Example

See the ASPocxSamples\EasyCookieLogin sub-directory of the installation directory for a working sample.

Applies To

AuthentiX OCX Component

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

http://www.flicks.com/authentix/discover/main.htm

Back to the top of the FAQ