Steven Dowd
|
| Posted: 10/19/2002, 7:42 AM |
|
I had a problem where users of the same security level could edit each
others records,
I have added a user_id field into each db table, and on original input of
the record i grab the session(UserID) into the $flduser_id , and then later
on any edit pages i do a check in the befor show event as follows :-
$usernamecheck =
dlookup("users","first_name","user_id=".get_session("UserID") );
if ($flduser_id == get_session("UserID")) {
$flduser_id = $flduser_id;
} else if ($flduserid < get_session("UserID")) {
print "sorry $usernamecheck but this is not one of your entries and so
access to edit, is not available to you";
exit;
}
Can anyone see any problems with this , it does seem to work ok , and i have
tried hacking the url to try to get into the page vai different url vars,
but it seems to manage the problem ok
am i re-inventing the wheel here, or is this a suitable way to check who
'owns' the actual record entry, other than just a check for page security.
Steven Dowd
steven@dowd.info
|
|
|
 |
Michael Rachow
|
| Posted: 10/22/2002, 6:12 AM |
|
Hi Steven
The security feature of CodeCharge do protect webpages not content.
So, if you have an edit page every user with the corrensponding value of the
attribute secure
can edit data on that page.
Next you would show records for a specific user only. An user can then
edit his own records only because only these are displayed
(not because of security).
You have to take care that values that define the records to be displayed
are not
params (and are by that a part of the URL).
If a user changes some values there it is allowed to him to access this data
too
because from the viewpoint of security he is at the right level.
Greetings
Michael
"Steven Dowd" <newspost@dowd.co.uk> schrieb im Newsbeitrag
news:aorr0m$s7h$1@news.codecharge.com...
> I had a problem where users of the same security level could edit each
> others records,
>
> I have added a user_id field into each db table, and on original input of
> the record i grab the session(UserID) into the $flduser_id , and then
later
> on any edit pages i do a check in the befor show event as follows :-
>
> $usernamecheck =
> dlookup("users","first_name","user_id=".get_session("UserID") );
> if ($flduser_id == get_session("UserID")) {
> $flduser_id = $flduser_id;
> } else if ($flduserid < get_session("UserID")) {
> print "sorry $usernamecheck but this is not one of your entries and so
> access to edit, is not available to you";
> exit;
> }
>
> Can anyone see any problems with this , it does seem to work ok , and i
have
> tried hacking the url to try to get into the page vai different url vars,
> but it seems to manage the problem ok
>
> am i re-inventing the wheel here, or is this a suitable way to check who
> 'owns' the actual record entry, other than just a check for page security.
>
> Steven Dowd
>steven@dowd.info
>
>
|
|
|
|
Steven Dowd
|
| Posted: 10/22/2002, 11:44 AM |
|
Yes thats why i added the user_id into each database table as part of the
original record
I then now lookup that as part of the edit page,
so with this system , no one can edit another persons record , except that
person,
this now is person specific security , not page or 'level' specific..
works great too
Steven
"Michael Rachow" <mrachow@BeraCom.de> wrote in message
news:ap3irf$jkb$1@news.codecharge.com...
> Hi Steven
>
> The security feature of CodeCharge do protect webpages not content.
>
> So, if you have an edit page every user with the corrensponding value of
the
> attribute secure
> can edit data on that page.
> Next you would show records for a specific user only. An user can then
> edit his own records only because only these are displayed
> (not because of security).
>
> You have to take care that values that define the records to be displayed
> are not
> params (and are by that a part of the URL).
> If a user changes some values there it is allowed to him to access this
data
> too
> because from the viewpoint of security he is at the right level.
>
> Greetings
> Michael
>
>
> "Steven Dowd" <newspost@dowd.co.uk> schrieb im Newsbeitrag
>news:aorr0m$s7h$1@news.codecharge.com...
> > I had a problem where users of the same security level could edit each
> > others records,
> >
> > I have added a user_id field into each db table, and on original input
of
> > the record i grab the session(UserID) into the $flduser_id , and then
> later
> > on any edit pages i do a check in the befor show event as follows :-
> >
> > $usernamecheck =
> > dlookup("users","first_name","user_id=".get_session("UserID") );
> > if ($flduser_id == get_session("UserID")) {
> > $flduser_id = $flduser_id;
> > } else if ($flduserid < get_session("UserID")) {
> > print "sorry $usernamecheck but this is not one of your entries and so
> > access to edit, is not available to you";
> > exit;
> > }
> >
> > Can anyone see any problems with this , it does seem to work ok , and i
> have
> > tried hacking the url to try to get into the page vai different url
vars,
> > but it seems to manage the problem ok
> >
> > am i re-inventing the wheel here, or is this a suitable way to check who
> > 'owns' the actual record entry, other than just a check for page
security.
> >
> > Steven Dowd
> >steven@dowd.info
> >
> >
>
>
|
|
|
|
dsafar
|
| Posted: 10/24/2002, 7:41 AM |
|
Check your code line - } else if ($flduserid < get_session("UserID")) {
change the < to <>, otherwise a person with a userid > than the record
userid could view it.
"Steven Dowd" <newspost@dowd.co.uk> wrote in message
news:aorr0m$s7h$1@news.codecharge.com...
> I had a problem where users of the same security level could edit each
> others records,
>
> I have added a user_id field into each db table, and on original input of
> the record i grab the session(UserID) into the $flduser_id , and then
later
> on any edit pages i do a check in the befor show event as follows :-
>
> $usernamecheck =
> dlookup("users","first_name","user_id=".get_session("UserID") );
> if ($flduser_id == get_session("UserID")) {
> $flduser_id = $flduser_id;
> } else if ($flduserid < get_session("UserID")) {
> print "sorry $usernamecheck but this is not one of your entries and so
> access to edit, is not available to you";
> exit;
> }
>
> Can anyone see any problems with this , it does seem to work ok , and i
have
> tried hacking the url to try to get into the page vai different url vars,
> but it seems to manage the problem ok
>
> am i re-inventing the wheel here, or is this a suitable way to check who
> 'owns' the actual record entry, other than just a check for page security.
>
> Steven Dowd
>steven@dowd.info
>
>
|
|
|
|
Steven Dowd
|
| Posted: 10/24/2002, 1:29 PM |
|
yes , i realised this after i posted it
"dsafar" <no_spam_dsafar@cool-offers.com> wrote in message
news:ap90r6$hh1$1@news.codecharge.com...
> Check your code line - } else if ($flduserid < get_session("UserID")) {
> change the < to <>, otherwise a person with a userid > than the record
> userid could view it.
>
> "Steven Dowd" <newspost@dowd.co.uk> wrote in message
>news:aorr0m$s7h$1@news.codecharge.com...
> > I had a problem where users of the same security level could edit each
> > others records,
> >
> > I have added a user_id field into each db table, and on original input
of
> > the record i grab the session(UserID) into the $flduser_id , and then
> later
> > on any edit pages i do a check in the befor show event as follows :-
> >
> > $usernamecheck =
> > dlookup("users","first_name","user_id=".get_session("UserID") );
> > if ($flduser_id == get_session("UserID")) {
> > $flduser_id = $flduser_id;
> > } else if ($flduserid < get_session("UserID")) {
> > print "sorry $usernamecheck but this is not one of your entries and so
> > access to edit, is not available to you";
> > exit;
> > }
> >
> > Can anyone see any problems with this , it does seem to work ok , and i
> have
> > tried hacking the url to try to get into the page vai different url
vars,
> > but it seems to manage the problem ok
> >
> > am i re-inventing the wheel here, or is this a suitable way to check who
> > 'owns' the actual record entry, other than just a check for page
security.
> >
> > Steven Dowd
> >steven@dowd.info
> >
> >
>
>
|
|
|
|
|
