numero = 36465
interpreted = N
texte = I would add that the search you wrote Peter doesn't check for default blankusername/password, right? (I.e. if they are blank as they are when the user firstcomes in a domain or fails an authentication then search finds *all* the clientrecords.)You could use grouped fields so you check the same field twice - once for the validvalue and once to *Not Equal* [blank] - all in the same search (do it for each ofusername and password)... OR use the multigroupchecker code (it comes free withwebcat Steve) which first does 2 quick lookups to see if username or password are stillblank for this domain before the search Peter offered...-JohnPeter Ostry wrote:> on 23.08.2000 21:19, Steve Dannaway at smdannaway@ualr.edu wrote:>> > So what I've whipped up is another version of our templates that allows a> > client to check their account. Since I'm on Typhoon, I did this with a> > context. In case I'm not using the correct terminology, this is what I am> > talking about: .> >> > What I have found, however, is that someone with a little knowledge of HTML> > can download the form, modify the client name and then gain access to> > another client's account.>> First, use long and meaningless ID's rather then real names.>> Second, each client has to have a login.> Write some code to check the permission and [include] it on top of every> page.>> For example:> [include /_includes/checkaccess]>> And this would be the file checkaccess:> [search db=clients.db&eqDB_USERdatarq=[username]&eqDB_PASSdatarq=[password]]> [showif [numfound]=0]> [authenticate]> [/showif]> [/search]>> DB_USER and DB_PASS are two fields of your database. [username] and> [password] ask the browser for this values. Everytime the browser doesn't> have the correct data, the authentication window pops up.>> Additionally you might check the referrer on each page wether the request> comes from within your site or not. Remember, if one tries to cheat, his> faked form can not be on your sever...> [hideif [getmimeheader host]^www.iea.ualr.edu]> Please stop this immediately, you are already in the log. > I believe you know what we mean. > If not, call the system administrator.> [/hideif]> I would immediately send a mail and/or pager message to the administrator,> including IP address, username, password, mimeheaders, everything you can> get from this guy.>> Peter>> -------------------------------------------------------------> This message is sent to you because you are subscribed to> the mailing list .> To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > Web Archive of this list is at: http://search.smithmicro.com/-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/
Associated Messages, from the most recent to the oldest:
I would add that the search you wrote Peter doesn't check for default blankusername/password, right? (I.e. if they are blank as they are when the user firstcomes in a domain or fails an authentication then search finds *all* the clientrecords.)You could use grouped fields so you check the same field twice - once for the validvalue and once to *Not Equal* [blank] - all in the same search (do it for each ofusername and password)... OR use the multigroupchecker code (it comes free withwebcat Steve) which first does 2 quick lookups to see if username or password are stillblank for this domain before the search Peter offered...-JohnPeter Ostry wrote:> on 23.08.2000 21:19, Steve Dannaway at smdannaway@ualr.edu wrote:>> > So what I've whipped up is another version of our templates that allows a> > client to check their account. Since I'm on Typhoon, I did this with a> > context. In case I'm not using the correct terminology, this is what I am> > talking about: .> >> > What I have found, however, is that someone with a little knowledge of HTML> > can download the form, modify the client name and then gain access to> > another client's account.>> First, use long and meaningless ID's rather then real names.>> Second, each client has to have a login.> Write some code to check the permission and [include] it on top of every> page.>> For example:> [include /_includes/checkaccess]>> And this would be the file checkaccess:> [search db=clients.db&eqDB_USERdatarq=[username]&eqDB_PASSdatarq=[password]]> [showif [numfound]=0]> [authenticate]> [/showif]> [/search]>> DB_USER and DB_PASS are two fields of your database. [username] and> [password] ask the browser for this values. Everytime the browser doesn't> have the correct data, the authentication window pops up.>> Additionally you might check the referrer on each page wether the request> comes from within your site or not. Remember, if one tries to cheat, his> faked form can not be on your sever...> [hideif [getmimeheader host]^www.iea.ualr.edu]> Please stop this immediately, you are already in the log. > I believe you know what we mean. > If not, call the system administrator.> [/hideif]> I would immediately send a mail and/or pager message to the administrator,> including IP address, username, password, mimeheaders, everything you can> get from this guy.>> Peter>> -------------------------------------------------------------> This message is sent to you because you are subscribed to> the mailing list .> To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > Web Archive of this list is at: http://search.smithmicro.com/-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/
John Butler
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...