rustypup wrote:never... never... send credentials in plain...
use the provided username and password to produce a comparable fingerprint, (even a simple MD5 hash).
secondly, don't confirm access via a boolean or bit switch... use an opaque code, or deliver a failed page...
Passing the username does not mean it is in clear text. TBH it is more like passing a search parameter to a stored procedure on a SQL server over an encrypted tunnel to port 1433 on a SQL server. Nothing llike passing credentials. The user already has to be logged in. The only thing done is that the stored proc uses the, already authenticated, user's name to internally check access rights to specific data and then return what is relevant to the user's rights rather than returning everything.
psudo code..... customer search...... whatever...
Code: Select all
create stored proc with parameters userid, customernamewildcard
begin
create a table variable in which to temporarily store data in the memory of the server rather than using a temp table which will cause extra disk IO
create a cursor which will loop through the customers which is returned when searching for the customernamewildcard in the customer's name field
for each customer
begin
if user is allowed access in the customer's region
begin
add the customer to the table variable
end
end
return the contents of the table variable
end
Doing it this way ensures that the access rights is abstracted from the actual front end code. It is however still a bundle of extra work for you and the server which has to run the database. So unless you have plenty of time and you have a killer of a server it is generally not a good idea to go and do this.
But lets consider what the above will do....
If the user has rights in Gauteng and he runs a customer search the stored proc will only return what the user has rights to see. If the customer he is searching for is located in Limpopo then the customer won't be returned by the stored proc and thus the user won't see the customer.