Re: Replace context problem ...

This WebDNA talk-list message is from

1997


It keeps the original formatting.
numero = 12529
interpreted = N
texte = >It seems that you have run into the problem I had the other day regarding >$Delete. I wanted to have an 'Admin Delete' function to delete records >enter by someone else.Hi Glenn,I've run into problems with this situation several times over the past 6-9 months, but mostly because I didn't really understand the hierarchy WebCat uses to check username and password values in this special situation - until now, that is.A long time ago, Grant created a special security feature for databases that have both a username and password field - because he wanted records in those databases to be protected from random deletion by unauthorized users who might decide to type in a $delete command into Netscape ... and thereby trash the database.Back then, PCS recommended creating databases with both username and password fields, because this would make it impossible for someone to use $replace or $delete to change or delete a record unless that person had also entered the proper username/password values for the record they were trying to replace or delete.Of course, this was done before PCS added the CommandSecurity feature.Now that the CommandSecurity feature is available, that 'special case scenario' with the username and password fields doesn't seem so important anymore ... and in fact it causes problems for the administrators of a site that has this situation.As the administrator of my web site I would like to be able to update ANY record in ANY database. This seems like a reasonable request, right?Okay, so in order to do that, first I have to type my own username/password into the browser's authentication box in order to access the [protected] page for my admin replace template. So far, so good. I enter MY admin username and password into the browser's authenticate box and I can then access the replace form.But WebCat doesn't let me replace that data ... no matter how hard I try ... because it insists on using the same username/password valuesI typed in earlier to compare them with the username/password values in the database record I'm trying to replace ... and since MY username/password values are different from this particular database record's username/password values, WebCat2 refuses to replace the data I want it to replace.I *thought* that by putting &username=[user]&password=[pass] into the replace context, that would tell WebCat2 to use THOSE values instead of the values already cached in the browser. But it doesn't work that way. Instead, WebCat2 ignore whatever values I tell it to use, and instead, it uses the username/password values in the browser's cache - every time. In this situation, there's apparently no way I can get WebCat2 to use the values I want it to use - it's always going to use the values cached in the browser - no matter what.Of course, I don't have to name the fields in my database 'username' and 'password'. The users.db that comes with WebCat2 names those fields 'user' and 'pass' instead ... probably to avoid this problem altogether.If there's no longer a security risk by keeping the field names 'username' and 'password' out of my databases, that's what I'll do ... :) >Perhaps changing to: > >[replace >db=xxx.db&SKUdata=[SKU]&username=[username]&password=[password]]fieldValuesHere >[ >/replace] > >would make the differance.Yeah, I spent about three hours on this the other day, and I tried everything - including this. But it doesn't make any difference what you do. As long as you have previously entered a username and password into the browser's authenticate box, you're not going to be able to change any of the data in a database that has fields named username and password ... except for records that actually have the same username and password values, of course.I was asking Grant if it would make sense to make WebCat2 use the username/password values I'm trying to get it to use - before trying to use the browser's username/password values. I don't know how the WebCat2 code is written, though, so I don't know if this even possible.Maybe it's just more practical to change my field names in my databases to something other than 'username' and 'password', and then this won't happen anymore. As long as the security risks are dealt with properly in other ways, this may very well be the way to go from now on ...Sincerely, Ken Grome WebDNA Solutions http://www.hui.net/dna/webdna.html Associated Messages, from the most recent to the oldest:

    
  1. Re: Replace context problem ... (Glenn Davis 1997)
  2. Re: Replace context problem ... (Kenneth Grome 1997)
  3. Re: Replace context problem ... (Glenn Davis 1997)
  4. Replace context problem ... and answers (Kenneth Grome 1997)
  5. Replace context problem ... (Kenneth Grome 1997)
>It seems that you have run into the problem I had the other day regarding >$Delete. I wanted to have an 'Admin Delete' function to delete records >enter by someone else.Hi Glenn,I've run into problems with this situation several times over the past 6-9 months, but mostly because I didn't really understand the hierarchy WebCat uses to check username and password values in this special situation - until now, that is.A long time ago, Grant created a special security feature for databases that have both a username and password field - because he wanted records in those databases to be protected from random deletion by unauthorized users who might decide to type in a $delete command into Netscape ... and thereby trash the database.Back then, PCS recommended creating databases with both username and password fields, because this would make it impossible for someone to use $replace or $delete to change or delete a record unless that person had also entered the proper username/password values for the record they were trying to replace or delete.Of course, this was done before PCS added the CommandSecurity feature.Now that the CommandSecurity feature is available, that 'special case scenario' with the username and password fields doesn't seem so important anymore ... and in fact it causes problems for the administrators of a site that has this situation.As the administrator of my web site I would like to be able to update ANY record in ANY database. This seems like a reasonable request, right?Okay, so in order to do that, first I have to type my own username/password into the browser's authentication box in order to access the [protected] page for my admin replace template. So far, so good. I enter MY admin username and password into the browser's authenticate box and I can then access the replace form.But WebCat doesn't let me replace that data ... no matter how hard I try ... because it insists on using the same username/password valuesI typed in earlier to compare them with the username/password values in the database record I'm trying to replace ... and since MY username/password values are different from this particular database record's username/password values, WebCat2 refuses to replace the data I want it to replace.I *thought* that by putting &username=[user]&password=[pass] into the replace context, that would tell WebCat2 to use THOSE values instead of the values already cached in the browser. But it doesn't work that way. Instead, WebCat2 ignore whatever values I tell it to use, and instead, it uses the username/password values in the browser's cache - every time. In this situation, there's apparently no way I can get WebCat2 to use the values I want it to use - it's always going to use the values cached in the browser - no matter what.Of course, I don't have to name the fields in my database 'username' and 'password'. The users.db that comes with WebCat2 names those fields 'user' and 'pass' instead ... probably to avoid this problem altogether.If there's no longer a security risk by keeping the field names 'username' and 'password' out of my databases, that's what I'll do ... :) >Perhaps changing to: > >[replace >db=xxx.db&SKUdata=[SKU]&username=[username]&password=[password]]fieldValuesHere >[ >/replace] > >would make the differance.Yeah, I spent about three hours on this the other day, and I tried everything - including this. But it doesn't make any difference what you do. As long as you have previously entered a username and password into the browser's authenticate box, you're not going to be able to change any of the data in a database that has fields named username and password ... except for records that actually have the same username and password values, of course.I was asking Grant if it would make sense to make WebCat2 use the username/password values I'm trying to get it to use - before trying to use the browser's username/password values. I don't know how the WebCat2 code is written, though, so I don't know if this even possible.Maybe it's just more practical to change my field names in my databases to something other than 'username' and 'password', and then this won't happen anymore. As long as the security risks are dealt with properly in other ways, this may very well be the way to go from now on ...Sincerely, Ken Grome WebDNA Solutions http://www.hui.net/dna/webdna.html Kenneth Grome

DOWNLOAD WEBDNA NOW!

Top Articles:

Talk List

The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...

Related Readings:

WebCatalog on G3 Macs? (1997) Developer Edition (2002) [WriteFile] problems (1997) Quit revisited (1997) Size Limitation through a POST via SSL? (2005) automatic reload of frameset (1997) question: writing files textb in webmerch (1997) WebCat2b15MacPlugin - showing [math] (1997) WebCat2: multiple currency support (1997) [WebDNA] WebDNA FastCGI (2012) Part 2 - [showif] if variable exists (1998) Re1000002: Setting up shop (1997) Before I Can Begin . . . (1998) problems with 2 tags (1997) quantity minimum problem (1997) problems with 2 tags (1997) Re2: Calculating multiple shipping... (1997) setting taxable to true (1997) Multiple catalog databases and showcart (1997) PIXO support (1997)