Mark,

We have used this strategy for many years on several different versions of 
Witango and Tera and have had no issues. We do not, however, use a number to 
load user type values (permissionlevel). I am not sure if that is the problem, 
though we have found in some unique circumstances that using 0 in if statements 
have been a problem. I don't see how an ifempty would be a problem with this 
because 0 should be a legitimate value. In the unique situations where we have 
had to compare 0 values as text rather than numbers, we have had to add a 
letter in front of each to get the comparison correctly. Somebody correct me if 
I am wrong, please. For instance if 001 = 1 would actually translate to true 
but a001 = a1 would translate to false. Also 00 = 0 is true but a00 = a0 is 
false.

Why this would suddenly stop working for you is a mystery.

John Muldoon
Corporate Incentives
3416 Nicollet Ave S
Minneapolis, MN 55408-4552
612.822.2222
[email protected]

http://cipromo.com

-----Original Message-----
From: D Mark Weiss [mailto:[email protected]]
Sent: Tuesday, October 01, 2013 5:26 PM
To: [email protected]
Subject: TeraScript-Talk: Login Problems

I believe I am still having problems with log in verification. I wonder if my 
strategy is wrong or if there is a more fool proof way to do it. This is a 
strategy I have used for years, and suddenly its' as if I am hitting browser 
cache before the actual URL is read or something like that.

Witango 5.5 mac osx server. apache and mysql.

when they log in

1. "If action"- We check to see if both username and password fields have 
content by using an if action checking for empty. If one or both are empty, we 
zoom them back to the log in screen.

2. We have next an "if action" responding to the _function=verify. We search 
the table for username and password. If we hit, we load a number of user 
variables, one of which is permission level. The majority of users have 
permission level "0" (zero). Then we go to the home screen.

3. from the home screen there are other menus. Here is where it gets strange 
and frustrating. Each menu refers to a different taf. In these taf's I have at 
the top an if action and end if. the If action checks for 
@@user$permissionlevel, to see if it  has expired in which case it would be 
"empty".   If it is empty then it sends them back to the log in screen. if it 
is not empty, it then cycles through the other if actions in that particular 
taf. We do it this way, because we use variables for important insert values 
and don't want to use URL parameters or hidden fields.

What seems to be happening over and over again, is that when branching from the 
home screen, (a separate taf) to another taf, even through I can verify that 
the variable hasn't expired, the if action still evaluates as if it had expired 
and sends the user back to the login screen. It checks @@user$permissionlevel 
to see if it's empty. It doesn't matter if the permissionlevel is 0 or 1 or 2, 
at one point or another, it still seems to evaluate as if it was empty.

So I tried a new strategy. Instead of checking for empty, I decided to check 
and see if @@user$permissionlevel is < 1. Perhaps I should just do a <@length 
"@@user$permissionlevel">  <  1 or <@calc> on the variable or something like 
that?

I have used this strategy in other apps for years and it seemed to work. 
Perhaps there is something in browsers that has changed and I need to change 
too. But in an otherwise very stable and helpful app, I am getting all kinds of 
complaints that it doesn't work and I guess I am at the end of my ideas. 
Permissionlevel of course controls access to all kinds of menus and functions 
by offering or not offering them to the user.

I am at this point very willing to learn an entirely new log in strategy if I 
need to. Thanks in advance for your help.

Mark



Mark Weiss
PhD Student
ITLS
Utah State University
435.363.6363
Mark Weiss
PhD Student
ITLS
Utah State University
435.363.6363




----------------------------------------

To unsubscribe from this list, please send an email to [email protected] 
with "unsubscribe terascript-talk" in the body.




----------------------------------------

To unsubscribe from this list, please send an email to [email protected] 
with "unsubscribe terascript-talk" in the body.

Reply via email to