7 replies to this topic

[PaulD]

When a user logs in, I can check if they are logged in on a page, and if so I can check they have permission, and if so I can then present the page contents. All this is clear enough.

But how do I get the page to present only the data that belongs to the user?

I imagine that I will have to add a column to my table for 'belongs-to' or 'user-id'. Then update all my table queries to include the extra WHERE clause where 'belongs-to' is equal to user-id. Is that correct?

If I do that though my url becomes something like: ....co.uk/index.php?a=1&View=3&userID=391

However then, by guessing different user ID's I could get another users data - couldn't I? (Assuming that the other member was logged in at the time I suppose).

Thank you for any help and clarification about how to best do this.


Also, I have a form or two on my page. Can anyone suggest a way I can stop a page reload performing or attempting to perform an action again. ie; if I post data then a refresh re-posts the data.

I tried to add a timestamp, but then I need a new table to look up the stored timestamp and check it matches with the page request. But if they do sync out then users won't be able to delete etc. Any ideas or suggestions how I should do this too.

Thank you.

Paul

[Cris D.]

Quote

But how do I get the page to present only the data that belongs to the user?

I use $_SESSION['internalKey'] which is only set if they are logged in and is unique for each user and there is no need to "retrieve it" as it is already stored in the session data.

Quote

I imagine that I will have to add a column to my table for 'belongs-to' or 'user-id'. Then update all my table queries to include the extra WHERE clause where 'belongs-to' is equal to user-id. Is that correct?

Again, I use a table field internalKey and make the where clause $where='internalKey=".$_SESSION['internalKey'];

Quote

Also, I have a form or two on my page. Can anyone suggest a way I can stop a page reload performing or attempting to perform an action again. ie; if I post data then a refresh re-posts the data.

Perhaps there is an easier way that I don't know but perhaps a time between submits in seconds? like a spam protect? otherwise it throws an error...

$lag=2000; 
$timelag=time() + $lag;
if($_POST['timelag']> time() ) return "Don\'t refresh you cheater!";

(Maybe there's an easier way).

Quote

I tried to add a timestamp, but then I need a new table to look up the stored timestamp and check it matches with the page request. But if they do sync out then users won't be able to delete etc. Any ideas or suggestions how I should do this too.

Paul, I'm sorry, I have no idea what this means!

[PaulD]

Thanks for that, really helps.

How do I link the user to the internal key. Would I write the internalkey during the login process? Or would it be during the user checking process? Or could I write it just in the top of the relevant snippet.

Are they logged in -
no - chuck them out again.

If logged in, do they have permission -
no - chuck them out again

If logged in and have permission, is the internal key written?
no - write internal key

The timestamp idea was that each url is written ...co.uk/index.php?a=3&TimeStamp=5:45pm (say!) which is stored somewhere. Then if the next action is a=3 BUT the timestamp is the same as the last action then don't do it. BUT if I try to delete one record after the other it would not let that happen, when really it should. So it didin't work. Just newbie madness I reckon on my part. :-)

The time delay would prevent accidental double clicks, thank you for that. I know that many sites suffer from refresh performing the same action, so I imagine that I will just have to live with that. I am worried that it will cause a crash though if someone refreshes and action that can't be repeated, like deleting a certain id.

In fact, it might only be delete that causes a problem. Perhaps a confirmation box on delete would solve it, with a simple warning. I can then just stop the delete function from crashing - a much simpler problem.

I have 19 actions (which to me was lots and lots) but I couldn't believe it when I looked at eto's switch, it goes up to about a hundred different actions. It is funny, but it is only when you try building a system yourself from scratch that you realise how much work has gone into eto. I have been trying to copy the click and drag for ages but still havent managed it (from the document tree). Partly because I don't want frames but mostly because it stretches my coding knowledge to breaking point!

Thanks for you help, much appreciated.

Paul.

Edited by PaulD, 23 January 2008 - 04:16 PM.

[Ralph]

I'm only going to tackle the internalKey part at the moment... When a user successfully logs in, or authenticates, that users session receives some very important data for later use... First, $_SESSION['validated'] is stored with a value of 1, meaning that the user authenticated... Next, $_SESSION['internalKey'] is stored with the users distinct user number, internalKey... The session also gets loaded with all of the users current Role settings, in $_SESSION['roles'], as an array, so they can be checked by the API function checkPermissions(), which also does document group checking if that feature is enabled in the configuration...

[PaulD]

Thanks Ralph,

I shall enjoy testing this out tonight. Although xampp doesnt always handle the logging in and out very well and I will probably have to wait till Thursday to try it properly. (Bloody customers - they may pay the mortgage but they don't always excite the grey matter!!)

Speak soon and thank you again,

Paul

EDIT: PS Xampp was blameless, I got it wrong, apologies to Xampp and now working great. The internal key seems to be working well too (just some simple tests done). Thank you. Now going to update the php I am writing and then TRY IT LIVE! I am childishly excited by this :-)

Edited by PaulD, 23 January 2008 - 04:17 PM.

[PaulD]

Just a quickie!

Is $_SESSION['internalKey'] always the same as user ID?

If not, how do I get the associated user ID. Do I just do a getIntTableRows from users table?

Thank you - Paul.

[Cris D.]

This is from the index.php file where all this stuff is colllated and the API's defined:

	$sql = "SELECT ".$this->db."manager_users.*, ".$this->db."user_attributes.* FROM ".$this->db."manager_users, ".$this->db."user_attributes WHERE ".$this->db."manager_users.username REGEXP BINARY '^".$username." and ".$this->db."user_attributes.internalKey=".$this->db."manager_users.id;";
	 $rs = $this->dbQuery($sql);
 <<SNIP>>
 $row = $this->fetchRow($rs);
 
	 $_SESSION['shortname']		 = $username;
	 $_SESSION['fullname']		  = $row['fullname'];
	 $_SESSION['email']			 = $row['email'];
	 $_SESSION['phone']			 = $row['phone'];
	 $_SESSION['mobilephone']	   = $row['mobilephone'];
	 $_SESSION['internalKey']	   = $row['internalKey'];
	 $_SESSION['failedlogins']	  = $row['failedlogincount'];
	 $_SESSION['lastlogin']		 = $row['lastlogin'];
	 $_SESSION['role']			  = $row['role'];
	 $_SESSION['lastlogin']		 = $lastlogin;
	 $_SESSION['nrlogins']		  = $row['logincount'];

So you can see that all these session variables are called from the manager_users and user_attributes table.

To answer your question more succinctly, yes, it always comes from the row that matches the internalKey and username (which is always unique) of the user_attributes table.

There is another API yoou might like to use:

function userLoggedIn() {
   // returns an array of user details if logged in else returns false
   // array components returned are self-explanatory
	 $userdetails = array();
	 if(isset($_SESSION['validated'])) {
	   $userdetails['loggedIn']=true;
	   $userdetails['id']=strip_tags($_SESSION['internalKey']);
	   $userdetails['username']=strip_tags($_SESSION['shortname']);
	   return $userdetails;
	 } else {
	   return false;
	 }
   }

$user=$etomite->userLoggedIn();
print_r($user);
will return:
array(['loggedIn']=>true,
['id']=>$_SESSION['internalKey'],
['username']=>username)
or return false if not logged in.


This returns the id and username of the current logged in person.

Edited by Cris D., 07 February 2008 - 05:08 PM.

[Ralph]

@PaulD

Yes, but only for authenticated users... Cris gave a good explanation...