wow, duh… I just commented on one that was last year. there needs to be more posts on here, so when I comment, it looks recent. LOL
On May 27, 2014, at 11:01 PM, Ben Johansen <[email protected]> wrote: > have you tried using redirection (303) with userreferencearg instead of > branch. I’m not a big fan of branch > > On Oct 1, 2013, at 3:25 PM, D Mark Weiss <[email protected]> wrote: > >> 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. >> >> > > Ben Johansen > http://www.webspinr.com > [email protected] > Phone: 360-600-7775 > > > > > > > > > To unsubscribe from this list, please send an email to > [email protected] with "unsubscribe terascript-talk" in the body. Ben Johansen http://www.webspinr.com [email protected] Phone: 360-600-7775 ---------------------------------------- To unsubscribe from this list, please send an email to [email protected] with "unsubscribe terascript-talk" in the body.
