m i l e s LASSO TIPS for NEWBIES: 2.9 THE LOGIN ROUTINE
Sep 26, 2005; 12:16
m i l e s
LASSO TIPS for NEWBIES: 2.9 THE LOGIN ROUTINE
- Hi and Welcome to -
++++++++++++++++++++++++++++++++ LASSO TIPS FOR NEWBIES: 2.9 ++++++++++++++++++++++++++++++++
I'm your host, M i l e s.
First and foremost, a good place for you to start with Lasso is the following 4 things:
The FIRST LASSO TIPS FOR NEWBIES -> http://www.listsearch.com/lassotalk.lasso?id=143312 The LAST LASSO TIPS FOR NEWBIES -> http://www.listsearch.com/lassotalk.lasso?id=149158 10 LASSO RESOURCES -> http://www.listsearch.com/lassotalk.lasso?id=143018 THE LASSO RESOURCES ADDENDUM -> http://www.listsearch.com/lassotalk.lasso?id=143417
++++++++++++++++++++++++++++++++ TODAYS TIP: The Login Routine ++++++++++++++++++++++++++++++++
Today's tip has a lot of information in it, and if you've been reading my posts over the last few weeks/months while Ive been on hiatus on the Lasso list you've seen me make the same post over and over again....the Login Routine! Because there's a lot of information to convey in today's tip, I'll try to keep the chit-chat short. However let me point out from the start that my solution to a LOGIN routine is NOT everyone's solution, it just happens to be my methodology to it. I have spent the better portion of 5 years working out this routine, and over the last year heavily writing it and rewriting it getting it to a point of stable functionality, which is the goal of any good developer - get it to work, get it to work correctly - you get paid. Now if only Doctors and Lawyers worked that way. Its still not perfect but it does work and it works well. My solution entails the use of SESSIONS, so if you haven't used sessions, you will now and you'll thank me for it later. Also this solution does not take into account being MULTIUSER aware, meaning types of users. For that, you'd have to rewrite this logic, completely. I know...Ive done it. With multiple login types you will need to rewrite the better portion of the validation and session logic. And this solution doesn't take that into consideration, but the roots of it are there...my current solution (which you're about to see) was actually stripped of this functionality so that you could see the basics.
PART ONE: Login! Vee Don't Need NO Stinkin' Login!
Like hell you don't. Nearly ever data driven website on the internet today has some kind of login routine that it requires in order to garner from the user who they are, what their user preferences are (or could be), and then redirect that user to their specific record or series of records that pertain to them and them alone. Because you don't want an end user to see anyone else's data, you want them to see ONLY their information...you have to provide some level of security, or at least make it appear as such. Let me say from the outset that this solution is database independent. Meaning you can use FileMaker for this, if you want, however you'd be better off with a SQL solution across the board for a variety of reasons, not the least of which is (separately) speed and security.
The things you'll need are essentially 3 pages, which can be combined into 1 but for the purposes of this LassoTip we're going to put them into their separate pages. I will comment out and explain where necessary, but is assumed here that you have a basic understanding of FORMS and their function.
The Login Form. The form itself (below) is really just a basic form. It consists of TWO fields, a username and password field. Note that the form name/value pairs are NOT being processed by the form, or by a lasso cgi (that's the ACTION statement), and also note that the submit statement is a NOTHING subtag. You should get into the habit of using the -NOTHING tag for all form submissions. It allows you greater flexibility on the receiving side of the form to do what you want to do with the data.
In the form above, I've made the name/value pairs very simple for purposes of easy reading, however, ideally what you want to do, is change the names of the name fields to be something innocuous. And the reason being is that as FMP developers or new developers you'll have a want to send the name of the actual field that you're searching on. That's a no-no, a security risk. Never ever do that. So ideally if this were the real world, you might want to do the following to your field names:
As you can see, the name side of the name/value pair has been anomynized. You could use this form for anything. Its only on the receiving side of things where the actual values of the form will get played with so you're not locked into anything here...it just gives you LOTS of freedom to play with data. Also note one other thing here, that the password field is denoted as a password and NOT a text field. While this is strictly an end user thing, the password while appearing as dots will be sent in clear text, UNLESS the site is using an SSL certificate. This tip does not deal with SSL certificates but it should be noted that ANY form values sent via the internet unless otherwise encrypted will be sent in clear text. That means in layman's terms, that if you're sniffing the TCP stream from another computer on the network, you will literally see the form values being sent to the server in the TCP stream unencoded.
PART TWO: Validation and Starting a Session.
For the validation page, as I like to refer to it, I like to run the whole thing as a LassoScript, you can run it as Lasso Square Bracket but LassoScript has one advantage over LSB, and that is that is doesn't take up space in a browser, meaning there are no carridge returns to report back to the browser. No output to the browser at all. I find it easier to read than LSB code but that's a personal preference.
// SECTION 1
var: 'e1' = (action_param: 'e1'), // set username 'e2' = (action_param: 'e2'); // set password
//note: ALWAYS ALWAYS ALWAYS convert your action_parameters to variables!
else; // this is where we redirect the end user back to login for failure.
/if; /protect; /inline; ?>
The script above is rather straight forward, however let's go through this section by section.
SECTION 1. This section deals with converting the two form parameters, the VALUES or left side of the Name/Value pair into variables so that we can use them. While this practice of converting ones action parameters into variables is a good practice to get into for several reasons, not the least of which is the fact that action_parameters can be LOST once acted upon. Variables can not. Or more to the point, they can't be changed, or reused inside an inline.
SECTION 2. This section deals with 2 things primarily. The first is the inline that will do the actual search against the db, and the second is the protection of the results, which we'll get to in a bit.
Firstly take a gander at the inline. Note that it doesn't look like your normal inline, primarily because its missing somethings, like database names, table names, and keyfield values. That's because, and this is again a personal preference as well as convention of the day in the lasso world in general, that to give you greater flexibility with your inlines, you create database connection variables. These are variable arrays that allow you to literally anonymize your datasources, making your logic somewhat independent of the datasources being used. Why do this ? Flexibility. Your databases may change over time....and rather than hardcode the database and tables throughout your applications, you put those values into an array, and then call the array as a variable. The second thing about this inline is that it is doing an explicit search for EXACT values against the table in question. When you do an EXACT match its matching from LEFT TO RIGHT exactly as it appears in the field. If there's a stray character feed at the end of the form value for username (for instance) and you go to look for against the database, Lasso will return a NULL match, so its a good idea to STRIP your variables and form values of any stray characters that may get caught in the datastream. However for the purposes of this example we don't use this instance here. So to invoke an EXACT match against the fields in question, you use -OP='EQ'. This means in layman's speak, USE THE OPERATOR 'EQUALS' AGAINST FOLLOWING FIELD ONLY, SEEKING THIS EXACT VALUE ONLY. Hmmm wow, all that contained in 8 chrs. Note that there are two of these operators. One for each field. If those operators weren't there, Lasso would pull back a multitude of potential responses that may match what you were after. By default Lasso performs a begins with (or -op='bw') search from left to right, that means if you search for '11234' against a series of records that contains '11245', '12345', '01134', and '23456', it will pull back '11245', '12345', as valid responses. So if you don't tell it to perform an explicit search against the fields in question it will search from left to right finding all sorts of potential matches!
Protection. This line, literally protects the code that's contained within the enwrapped code from displaying to the end user an kind of error in any way, shape or form. This is more for your app to look pretty so that you don't see an ISE or the dreaded Lasso Blue Banded Error Screen, and your clients don't think you're an idiot who couldn't code your way out of a wet paper bag.
SECTION 3. This section deals with a successful finding of ONE SINGULAR record, and the creation of a session and its variables, as well as its opposite, the NOT finding of a one singular record that matches the exact parameters of the search in question.
Two things of note here is starting the session itself, note Im using LINKS instead of cookies. As with sessions you have the option to use both, I prefer not to expend the processing power that way, just use links. Much safer that way. Secondly is setting a timelimit to the session itself. By default sessions are implimented for 20 minutes, however, I find that that's not long enough for most uses. 30 is better. YMMV.
Setting the session is easy, so how do you populate it ? I have one request that I'd like to see in how sessions are implemented in the next version of Lasso and that's to directly TIE a session variable to a value like session var = "some value". However that's not how this game gets played. Nope. You'd think that's how it works but it doesn't. Note after I set the session variables, I also create and populate 3 variables. The 3 variables also happen to have the same name as my session variables. So NOW those session variables are populated. Yipppee. Confused the hell out of me first couple of times I used sessions. OP ? Listening ? SESSION VARIABLE = SOME VALUE! Drives me nuts. Ok, done with my soap box.
Once all you've got your session variable set and populated, you direct the end user to their specific datapage. And that's exactly what I do.
If the end user IS NOT FOUND or there isn't an exact match then we redirect to the login page.
But first....a word from our sponsors...
PART THREE: THREE LICKS.
So just how many licks does it take to get to the center of a tootsie roll pop ? Let's find out. ONE, TWO....THREE! <-CRUNCH-> Yes! Three! And that my friends brings us to PAGE 3 of our lil toy the actual userpage.lasso. In short once you've got your user to their data page, this is the simple part, and all you need do is check to see if their session is a valid one, and keep doing that. What follows is the entire logic of userpage.lasso and any page, in actuality, where you're needing to force a login under any condition. What this logic does is ask the all important question, are you a valid session ? IF you are, great here's the data associated with that session, if you're not BAM! you get booted:
"Wait. Ummmmm Mister Miles...didn't you already start the session on the login-validate.lasso page ?"
Why yes I did. And now we have to start it again. You see because the web is a stateless place we have to have some way of keeping state and that's exactly what we're doing. In short, we're identifying THIS page with the state we already created. Yes I know its a bit confusing, because you're starting the session again. I know that. However, listen to your old pal Miles here. You're starting it again. HOWEVER that's a misnomer. What you're actually doing is CHECKING the session here. Lasso knows its you. The language just doesn't allow a more intuitive mechanism. (OP ? You listening, again ? Helpful hint for LP9 - Session Language needs a tweak. ) That said....all you're doing is checking the session here, that's it. How does it relate back to you or know that that session is the right session? Look at the URL that's been generated, note the session ID value? That's how it knows. This value will pass from page to page, or propagate automatically from page to page, as long as you start the session at the top of every page that you need to carry session variables.
2.) We're calling the session variables, again this is a misnomer. Because the first time we did this, it was literally adding those values. Now we're not adding values, we're calling them. They already have values. We can change them if we want by setting variables with the same names further down on the page, and the next time we call them, they'll have NEW values. However all we're doing is calling them, and once we've done so, they're now available to the page that we're on.
3.) SESSION_RESULT. This lil toy saved me HOURS of coding, and I mean HOURS of coding. Session_Result has THREE possible values: NEW, LOAD, or EXPIRE. In this instance, the session "ACCESS" is in LOAD condition, and it will continue to be in LOAD condition as long as we're active. (IE: we keep clicking links) However the clock is ticking, if we step away from our computer for up to 29 minutes & 59 seconds, the session is still active and all we need do is click on any link which will reset the session clock back to 30. However, if we reach the 30 minute mark, the session goes stale and BAM! Our session_result is now equal to EXPIRE and that may friends is what v_sessioncheck is all about... I set a variable for session_result to equal v_sessioncheck no matter what it is.
And we note that $v_sessioncheck is checking to see if the value is NOT expire. If its either NEW or LOAD, run the page contents inside the IF statement...else boot them to the login page.
This is just a small example script and bit of logic that can 'simulate' a login experience. I say simulate because they're not actually logging into anything, lasso is basically checking them against a series of values in the database (username/password), and then allowing them to see records related to them from there. Remember its a simulation. If this were an actual database...yadda yadda yadda. Just kidding. In short, this is one of many ways to accomplish the concept of a login. YMMV. Play around with it. Please. If you discover a better way, please by all means share with the group.
Three things to point out here:
1.) This solution does not have anything in any way, shape or form to do anything with Lasso Security. It does not replace it, it does not remove it....it does however if you've read my methodology on db_connection array variables use lasso security in that respect.
2.) This solution can be defeated (to a degree), and if you can tell me how and why, offlist, AND your the first person that gets it right, I'll send you a box of your favorite chocolate. However, the solution must be sent to me privately. If its submitted publicly I will not accept it as a valid response. I will post the results of how and why, and how to build a better mousetrap in a later LTÆ’N/F. IF no one gets it, that's alright...I still have to show you how to build a better mouse trap and trust me there is a better mouse trap!
3.) The Better Mouse Trap ? Requires a LOT programming, not to mention an SSL certificate, AND Two Sessions with longer IDS. And that's just for starters. Which should give you a hint as to how to defeat this mouse trap.
In future as LASSO TIPS moves forwards, I would ask that if someone has a comment about a tip, please change the subject line accordingly....its a request people, not a demand.
That said...Happy Lassoing.
M i l e s.
â€“â€“â€“ LASSO EVANGELIST FOR HIRE: GREAT RATES â€“â€“ NEEDS WORK â€“â€“â€“ -don't know what lasso is ? - http://www.omnipilot.com/ â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“ M i l e s email@example.com MagicMiles Software (415) 686 - 6164 http://www.lassoevangelist.com/ AIM/Yahoo/MSN: magikmiles â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“ Creating custom content management systems for yoga, dance, healing arts, & now real estate starting at just $65.00 a month, incld: domain registration, web hosting, email and webmail, and access to TOOLBOXENGINE! A very robust tool. â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“â€“
-- ------------------------------ Lasso Support: http://support.omnipilot.com/ Search the list archives: http://www.listsearch.com/lassostudiotalk.lasso Manage your list subscription: http://www.listsearch.com/lassostudiotalk.lasso?manage
This site manages and broadcasts several email lists pertaining to Lasso Programming and technologies related and used by Lasso developers. Sign up today!