resetting StationEnvironmentVariable per user
Moderators: Tyler, Scott, PWB v2 Moderator
resetting StationEnvironmentVariable per user
Is there a way to reset the StationEnvironmentVariable based upon a login value (i.e. a username - perhaps stored in a cookie?) entered via a secondary app which would then launch PWB. We might want to do this so that by then enabling the UseUniqueHistoryFiles feature we could actually track activity by username. Thanks!
-
Guest
Yes, that sounds close to want we want.
However, we don't currently require our users to individually logon to and logoff from our network/machines (and we would like an area in our library where public user's can have browser access, but not network access) to use library resources and we do not want to create logon accounts for our non-institutional users.
In my first post I wrote 'login value' - but I did not have a 'windows login' in mind, rather a script which might run as the shell program requiring users to validate that they possess a current library account [card number] before PWB launches - and then as added benefits use the user's account number to track usage and maybe present users with different options (launch PWB with a different start page) depending upon their institutional affiliation.
Then by closing a PWB, or exiting via the inactivity timer it would run that script again setting up for the next user and would avoid having to logoff and logon. Accomplishing this with a windows logon seems a bit difficult given these objectives and restrictions (or maybe I'm just not thinking too good), it would be nice to be able to 'cache' a minimal amount of user info in each individual browser instance without requiring a windows logoff/logon.
However, we don't currently require our users to individually logon to and logoff from our network/machines (and we would like an area in our library where public user's can have browser access, but not network access) to use library resources and we do not want to create logon accounts for our non-institutional users.
In my first post I wrote 'login value' - but I did not have a 'windows login' in mind, rather a script which might run as the shell program requiring users to validate that they possess a current library account [card number] before PWB launches - and then as added benefits use the user's account number to track usage and maybe present users with different options (launch PWB with a different start page) depending upon their institutional affiliation.
Then by closing a PWB, or exiting via the inactivity timer it would run that script again setting up for the next user and would avoid having to logoff and logon. Accomplishing this with a windows logon seems a bit difficult given these objectives and restrictions (or maybe I'm just not thinking too good), it would be nice to be able to 'cache' a minimal amount of user info in each individual browser instance without requiring a windows logoff/logon.
We have a setup similar to what you're describing. I've put together logon scripts (VBScript) which do the following:
- verify a user against out current user list (patrons must have a signed form on file before going online)
- prevent more than one person from using the same card at the same time
- show warning and suspension messages, derived from our history and usage files, for policy violations
- give overrides for temporary cards that we issue at the desk
- keep track of daily time limits
- check the current account status in DRA
I believe you can add environment variables in VBScript as well, using the WshShell.Environment object. I didn't do that route; instead, I set the STATIONNAME environment variable on each station to be equal to the computer name (i.e. "Internet A," "Internet B," etc.). We use those settings in our URL history files and on printouts (in the footer on each page, the current card number and Internet station name are printed out so we can find out who the printouts belong to).
Got kind of long there but I hope that helps and gives you an idea of what you can do with those log-on scripts!
- verify a user against out current user list (patrons must have a signed form on file before going online)
- prevent more than one person from using the same card at the same time
- show warning and suspension messages, derived from our history and usage files, for policy violations
- give overrides for temporary cards that we issue at the desk
- keep track of daily time limits
- check the current account status in DRA
I believe you can add environment variables in VBScript as well, using the WshShell.Environment object. I didn't do that route; instead, I set the STATIONNAME environment variable on each station to be equal to the computer name (i.e. "Internet A," "Internet B," etc.). We use those settings in our URL history files and on printouts (in the footer on each page, the current card number and Internet station name are printed out so we can find out who the printouts belong to).
Got kind of long there but I hope that helps and gives you an idea of what you can do with those log-on scripts!
-
Guest
spragers - thanks for the response! Your setup sounds like it might address all of our objectives. One thing I don't understand - you say each printout displays the current card number - can you can tell me are you able to write that card number to the PWB history file/log as well? or does it just display in the printout footers of currently online users and then lost for tracking individual user activities when the browser closes? If a user's card number is not recorded in the history log - I don't know how we would document "inappropriate?" use by a user who crashes a PWB and walks away. Thanks again.
Because the environment variables are session specific you can not use a batch file to set the variable and then run PWB. The variable would only be set for the command box and PWB would not see the variable.
You can set the variables system wide, or per user via the computer properties. But this will not work for your desired end results.
It is possible to change the environment variables on the fly with an application. This application could be used in the PWB startup or shutdown script. Here is the way to do it.
#define WM_WININICHANGE 0x001A
#define WM_SETTINGCHANGE 0x001A
#define HWND_BROADCAST 0xffff
function FlushNTRegistry()
STRING szEnv;
POINTER pEnv;
// Flush the NT registry to all applications.
szEnv = "Environment";
pEnv = &szEnv;
SendMessage (HWND_BROADCAST, WM_SETTINGCHANGE , 0, pEnv );
Perhaps we can get a volunteer to write this small application. If not, I will write it when I get a few spare moments.
--Scott
You can set the variables system wide, or per user via the computer properties. But this will not work for your desired end results.
It is possible to change the environment variables on the fly with an application. This application could be used in the PWB startup or shutdown script. Here is the way to do it.
#define WM_WININICHANGE 0x001A
#define WM_SETTINGCHANGE 0x001A
#define HWND_BROADCAST 0xffff
function FlushNTRegistry()
STRING szEnv;
POINTER pEnv;
// Flush the NT registry to all applications.
szEnv = "Environment";
pEnv = &szEnv;
SendMessage (HWND_BROADCAST, WM_SETTINGCHANGE , 0, pEnv );
Perhaps we can get a volunteer to write this small application. If not, I will write it when I get a few spare moments.
--Scott
That code looks Greek to me 
HEADER = (Station Name) + (Card number)
- then set PWB to use HEADER as the environment variable.
(this isn't code, just showing what would need to be done)
We keep the card numbers and the log on/off information file separate from the URL history file for privacy reasons (we can match the two up if we need to - for example, I'm starting to issue automated warning messages to people who trigger our filters) - this way we don't have any user-indentity information directly connected to what sites they're visiting.
If you can add the card number to an environment variable (with a program as Scott suggested) then you could. i.e.can you can tell me are you able to write that card number to the PWB history file/log as well?
HEADER = (Station Name) + (Card number)
- then set PWB to use HEADER as the environment variable.
(this isn't code, just showing what would need to be done)
We keep the card numbers and the log on/off information file separate from the URL history file for privacy reasons (we can match the two up if we need to - for example, I'm starting to issue automated warning messages to people who trigger our filters) - this way we don't have any user-indentity information directly connected to what sites they're visiting.
spragers? You got me thinking, do you know if it is possible to create a header like this:
HEADER = (Station Name) + (Timestamp)
I guess that would really suffice for us, in some ways better:
1. user identities and activities would be in separate files - but we would still have the ability to look up and match user activity later if we felt a need to.
2. no-one would need to write the module Scott (thanks) described.
Even if we went with the approach Scott outlined, as you rightly point out spragers, we would need/want to create that kind of separation (maybe session id that we could trace back to a user) between user identity and activity. Thanks!
HEADER = (Station Name) + (Timestamp)
I guess that would really suffice for us, in some ways better:
1. user identities and activities would be in separate files - but we would still have the ability to look up and match user activity later if we felt a need to.
2. no-one would need to write the module Scott (thanks) described.
Even if we went with the approach Scott outlined, as you rightly point out spragers, we would need/want to create that kind of separation (maybe session id that we could trace back to a user) between user identity and activity. Thanks!
-
Philip - Long Beach NY
- Benefactor
- Posts: 82
- Joined: Fri Feb 28, 2003 2:30 pm
Maybe Scott and Spragers can get together and write a "module" that connects power to the keyboard and seat. Any "policy violations" will result in a voltage shock lifting the person 3 inches off the seat.
I think that would take care of any "violations" don't you?
MUAHAHAHAA
I think that would take care of any "violations" don't you?
MUAHAHAHAA
Complexity is the enemy of security
-- Steve Gibson
-- Steve Gibson