use token to store username?

[AndreasBoehmer]

There was a suggestion made in this thread http://www.fmforums.com/ubb/cgi-bin/ultimatebb.cgi?ubb=get_topic&f=21&t=000050

to store the username in a token after logging in, so that the user does not have to re-enter the username constantly.

I am wondering, whether that is a good solution or not? If somebody had a look at the Form that is being submitted on login, he would pretty easily see what is being done (username stored in token). Couldn't he then get around the whole security by simply entering a -token=someUsername into the URL at the top? Then he could continue working with the username ha just entered without having to go through the login procedure.

Or am I wrong there?

I am trying to find a halfway secure way of doing this (login with username and password and then have the browser or server remember the details).

Any pros or cons?

[Charlie Boisseau]

I had exactly the same problem. It was only until after I made the whole thing that I decided it was a bad idea. I got annoyed by having to put the -Token=[FMP-CurrentToken] tag into every link, form and button. If you don't do this, as soon as you click something that doesn't contain the tag it forgets the username. A much better idea is cookies. You only have to assign it once and you don't have to carry it on every link and form you write.

Look in to cookies. Much better idea. Learn from my mistake!

Let me know how it goes..

Cheers

Charlie

[John May - Point In Space]

I like writing my solutions so they use cookies if available, and tokens if not. That way you don't leave anyone out from accessing your site.

- John

[Anatoli]

quote:

---

Originally posted by chazboi:

I had exactly the same problem. It was only until after I made the whole thing that I decided it was a bad idea. I got annoyed by having to put the -Token=[FMP-CurrentToken] tag into every link, form and button. If you don't do this, as soon as you click something that doesn't contain the tag it forgets the username. A much better idea is cookies. You only have to assign it once and you don't have to carry it on every link and form you write.

Look in to cookies. Much better idea. Learn from my mistake!

Let me know how it goes..

Cheers

Charlie

---

I am sorry to tell you, but cookies works only in Netscape. It looks like they do work in MSIE, but after a while it will go bananas.

BTW, John May forum is based on cookies and it is not working for me in MSIE at all.

Tokens are not stored in browsers and you must carry them in all links. Not a big deal, just copy paste.

[AndreasBoehmer]

Hmmm.. thanks for the feedback. I will probably try out both and see how they work in IE and NEtscape.

The question I still have is how to stop an unfriendly user who is trying to get around the security to simply enter the token and its value into the URL himself?

The only thing I could come up with would be to do the username/password check every time you open a page. So take the currentToken and compare it with the username again.

But then - how would I do that? Seeing that I have got the usernames and passwords in a seperate database, I can't call that database every time I open a page, can I? I mean, I can only call one database per page, or am I wrong?

[Vaughan]

I'm a bit confused by the original question "I am trying to find a halfway secure way of doing this (login with username and password and then have the browser or server remember the details)."

Once logged-in, the browser *does* remember the userID and password. In fact, there has been much collective hair-pulling about how to get the browser to *forget* the password!

Are you using Web Security databases for access control?

[AndreasBoehmer]

No I am not. What I did is create a new database in which the usernames and passwords are being stored.

The login-form will ask for a username and a password. In the next step both are being checked whether they exist in that combination in the users-database. If so, I wanted to save a token with the username.

This is pretty much how I am doing it in ASP, except for in ASP the user cannot control the variable that is holding the username (in this case token).

So it sounds as if I am going down the wrong way? How do you get the browser to store the username (I noticed that it wouldn't forget the username when using the web security database, but how do I get that to work with my own database.

Sorry, as you can see I am new to the Filemaker business and CDML. But I am willing to learn!

[AndreasBoehmer]

Do you know perhaps of any sample login-system not using the web security database where I could have a look at the code? I am sure if I saw the CDML and everything it'd be easy to grasp. So far I just can't seem to get my head around it.

[Garry Claridge]

We are currently building a system with 16 tables and are using our own user/login table. Related to that table we have a log and a page-history.

Each format page has an inline-action which checks either Javascript variables in the framescript or cookies before it will continue.

This is working quite well. However, we are still 'fine-tuning' some areas.

Garry

[ August 02, 2001: Message edited by: garrycl ]

[AndreasBoehmer]

So how do I get the username and password to be stored in the browser then? I know there's something like FMP-ClientUsername, but how do I assign the value of the username to it?

Or do you store the username and the password in cookies?

What exactly is happening in your login-system and where do you store the data so that each new page knows that you are still logged in and what your username is?

Sorry, I guess this question is old, but I couldn't find any answers yet. You people are my last chance!

[John May - Point In Space]

If you use the web security database for your permissions, then it will authenticate any actions with a standard browser authentication dialog, and the user will remain "logged in" until they quit + restart their browser.

If you're using a separate database, the best thing is to authenticate the user with an [inline] on each page, as mentioned above. Check out Douglas Burchard's LockIt solution at http://207.86.86.78/lockit/ for some great examples of this.

- John

[Anatoli]

Forget about cookies. As a programmer you cannot rely on something what users are having chance to switch of.

You can store really weird usernames in tokens and then it will be not a simple task to guess something.

Second -- forbid users to generate and modify URL, use "Forced Frames" technique.

Third -- use 2 values, user name and password calculated together.

[AndreasBoehmer]

Thanks for the tips, guys!

John, I will have a look at the link in a second. Looks helpful, as far as I can see.

Anatoli, I was following the other discussions you guys had on using cookies or tokens. I see your point, there is a problem with cookies that are being controlled by users. But they give a halfway solution of loggin the user out again. Either by timing the user out or by deleting the cookie. I am not sure whether you can do that with a Token. But I will give it a try!

Thanks a lot!

[Krishan]

quote:

---

Originally posted by AndreasBoehmer:

If somebody had a look at the Form that is being submitted on login, he would pretty easily see what is being done (username stored in token). Couldn't he then get around the whole security by simply entering a -token=someUsername into the URL at the top? Then he could continue working with the username ha just entered without having to go through the login procedure.

---

This is a problem not just for Tokens. I was worried about somebody just entering -&UserName="blahblah".... So I created a field called "Login" and "LoginCookie". When the User successfully logged in (with correct UserName and Password) using the members login page, the next page had a "Continue" link. This Continue link basically edits the record. It edits the "Login" field to "In" (as opposed to out) and it edits the "LoginCookie" field to the "Client's IP Address". So I have two fields which can only be edited if you enter via the login page. Now the LoginCookie is also set as a cookie in the User's browser (and set to expire when the browser is closed). What I do is use IF logic statements. IF the field Login=In AND LoginCookie matches that in the database, then show normal web page. ELSE show re-login page. Also, when you sign out you edit the "Login" field to "Out" and the "LoginCookie" field to something different (to the IP address and hence different to that stored in the browser). And then I use forced frames to prevent people just easily changing the URL.

....hope I make a tiny bit of sense! lol.... Good Luck.

[ August 05, 2001: Message edited by: Krishan ]

[AndreasBoehmer]

That doesn't sound bad. I was thinking about making a step in between. Maybe I will have another play with it.

One problem I keep encountering with all these different variations is the comparison of stored data (in tokens or cookies) with the database.

Krishan, you say you compare the IP and the Login with the data you have got in the database. The problem I have is that I am using three different databases. One of them is holding the user data (is called "users"), the other two are for the website content. Now if I want to compare the cookies with the content of the database, I will have to call that database on opening of every website. But I also call one of the other two websites.

So I guess the problem I am having is how to call two databases in one go? The users to check whether the details are correct and the other database for the content. I guess an ODBC would be the easiest way to go again, but is there a possibility with CDML?

[John May - Point In Space]

You'd want to look into using [inline] operations. You can perform as many of these per page as you want.

- John

[Krishan]

quote:

---

Originally posted by AndreasBoehmer:

Krishan, you say you compare the IP and the Login with the data you have got in the database. The problem I have is that I am using three different databases. One of them is holding the user data (is called "users"), the other two are for the website content. Now if I want to compare the cookies with the content of the database, I will have to call that database on opening of every website. But I also call one of the other two websites.

---

I use three databases and one of them, the Users.fp5, contains the Users data. I make them related using the unique "UserID" which each user is automatically given. Then my other databases use the "::Login" and "::LoginCookie" fields from the Users.fp5.

When the User has logged in successfully with his correct UserName and Password, he is then asked to press a button to Continue signing in. On this "Continue" page it has the code:

code:

---

[FMP-SetCookie: LoginCookie={FMP-field: UserID}{ClientIP}]

---

So this places a unique cookie in the User's browser.

And the Continue link includes the following code:

code:

---

<a href="FMPro?-db=Users.FP5....&-RecID=[FMP-CurrentRecID]&LoginCookie=[FMP-field: UserID][FMP-ClientIP]&Login=In&-edit

---

This edits the LoginCookie and Login fields. Then on the web pages I have the IF statement:

code:

---

[FMP-If: CurrentCookie: LoginCookie .eq. field: LoginCookie]

[FMP-If: field: Login.eq.In]

....Then show normal Html.

[FMP-ElseIf: field: Login.eq.Out]

[FMP-include:relogin.html]

[/FMP-If]

[FMP-ElseIf: CurrentCookie: LoginCookie .neq. field: LoginCookie] [FMP-include:relogin.html]

[/FMP-If]

---

This prevents other people looking at your web pages unless they entered through the normal Login procedure and.... even if they did know your UserName and Password, they can not view the web pages at the same time as you (because of the unique cookie which is dependent on the IP address).

When Users click the Logout button then the Login field is edited to Out and the LoginCookie field is edited to something different to that originally stored in the User's browser.

I then have other databases which are related to the Users.fp5 database and contain the fields "::Login" and "::LoginCookie". I just change the IF statement at the very top of the page according to which database was used to create the web page. If it wasn't the Users.fp5 database then I would have to use the following code:

code:

---

[FMP-If: CurrentCookie: LoginCookie .eq. field: Users::LoginCookie]

[FMP-If: field: Users::Login.eq.In]

....Then show normal Html.

[FMP-ElseIf: field: Users::Login.eq.Out]

[FMP-include:relogin.html]

[/FMP-If]

[FMP-ElseIf: CurrentCookie: LoginCookie .neq. field: Users::LoginCookie]

[FMP-include:relogin.html]

[/FMP-If]

---

....hhhmmm..... I hope I make some sense. I don't know if it helps.... Goodluck..

[AndreasBoehmer]

I would love to use inline-action, but as far as I understand it's a FMP5-only feature, hey? I am stuck with FMP4, so can't use it.

If that is the only way to get information from two databases, I will probably have to try something similar to what Krishan did. I was thinking about it earlier on, but encountered the problem on how to define the relationship in each database.

If each user had his/her own site to view with his username/password, I guess it wouldn't be any problem. But in my case all users view the same records (it's a Forum similar to this one). That again would mean that all logincookies and logins would have to appear on each record in order to test for them. So I can't make a relationship to the UserID.

But I will play around with it and see what I can get.

The very last question I have is how to make an exactmatch in FMP4. How can I test whether the username matches exactly with the username in the database. At the moment, if somebody enters "a" as the username and "b" as the password, he's got pretty good chances of logging in. All he needs is a username to contain an "a" and the appropriate password to contain a "b" and he's in. Sorry about all these questions! But I need to ask them once to get going. Hope you forgive me. :-)

[Krishan]

quote:

---

Originally posted by AndreasBoehmer:

The very last question I have is how to make an exactmatch in FMP4. How can I test whether the username matches exactly with the username in the database. At the moment, if somebody enters "a" as the username and "b" as the password, he's got pretty good chances of logging in. All he needs is a username to contain an "a" and the appropriate password to contain a "b" and he's in. Sorry about all these questions! But I need to ask them once to get going. Hope you forgive me. :-)

---

I onced asked the same question on this forums board. Go to: http://www.fmforums.com/ubb/cgi-bin/ultimatebb.cgi?ubb=get_topic&f=12&t=000120

quote:

---

I found yafreax's advice useful. His words were:

Simply insert one of the following tags RIGHT BEFORE BOTH OF THE FIELDS YOU ARE SEARCHING:

<input type=hidden name="UserName" Value="=="> (two "=" signs)

OR

<input type =hidden name="UserName" Value="="> (one "=" sign)

---

I use just one "=" sign, it works fine, try both, i'm sure one of those will work.

....

[AndreasBoehmer]

Beautiful! I can remember reading that thread a while ago, but forgot about it meanwhile again!

Thanks so much for your help guys. In particular for the last one, Krishan!