Set rs = conn.Execute

Prøv sådan her:

Set rs = Conn.Execute("SELECT * FROM data WHERE [email] = '" & request("brugernavn") & "' AND WHERE [password] = '" & request("password") & "'")

//>Rune

du behøves kun [] omkring reserverede ord
Men din fejl er sikkert som medions har rettet at du ikke har ' omkring teksten
Når det er strenge i din database skal der altid ' omkring, hvis det er tal man sammenligner skal der intet omkring :o)

Der er ingen grund til at have []-klammer rundt om felt-navnene. Det er ikke reserverede ord.

;o)

bare en mente ...
1)
Det er "smartest" at benytte request.form eller request.querystrin afhængig af din form i stedet for blot request - det sparer lidt resourcer og men risikerer ikke at gå fejl af sine navne
2)
Hvis du vil undgå at folk kan udnytte din database bør du sikre dig mod sql injektion ved først at lave en replace(request("password"),"'","''= på alle tekst felter

busschou> Hehe, ja, men kunne sq ikke huske helt om "email" var et reserverede ord,så smækkede den om den alligevel ;-)

-min fejl, skulle måske også lige ha' oplyst dette...

//>Rune

nøh dit svar er såmen rigtig nok jo, der er intet galt i det
Ville bare forklare så spørger måske lærte lidt om hvad fejlen skyldtes, frem for blot at få en løsning forærende :o)

> Hvis du vil undgå at folk kan udnytte din database bør du sikre dig mod sql injektion ved først at lave en replace(request("password"),"'","''= på alle tekst felter

Ikke kun på det ene felt, men faktisk på alle felter, som indgår i SQL-strengen. I dette tilfælde også på request("brugernavn"). (Hvilket jeg dog er 100% på at busschou
godt ved - bare en lille smutter ;^).

Har prøvet med:

Set rs = Conn.Execute("SELECT * FROM data WHERE brugernavn = '" & request.querystring("brugernavn") & "' AND WHERE password = '" & request.querystring("password") & "'")

Det giver fejlen:
Syntax error (missing operator) in query expression

Der skal kun være eet Where
Set rs = Conn.Execute("SELECT * FROM data WHERE brugernavn = '" & request.querystring("brugernavn") & "' AND password = '" & request.querystring("password") & "'")

nielle >> hmm ja jeg lavede vist en stavefejl med et = som skulle være en ) men jeg skrev nu altså "på alle tekst felter" :o)

og det lidt mere sikre
Set rs = Conn.Execute("SELECT * FROM data WHERE brugernavn = '" & replace(request.querystring("brugernavn"),"'","''") & "' AND password = '" & replace(request.querystring("password"),"'","''") & "'")

Prøver lige noget andet:

Ingen vil kunne kende id'en i en post, så derfor id istedet får password, ok kunne jo også ha været alle 3.

Set rs = Conn.Execute("SELECT * FROM data WHERE email = '" & replace(request.querystring("email"),"'","''") & "' AND id = '" & replace(request.querystring("id"),"'","''") & "'")

Men med det eks. får jeg:
Data type mismatch in criteria expression.

Da id sikkert er et tal, så skal der ikke '-tegn rundt om dette:

Set rs = Conn.Execute("SELECT * FROM data WHERE email = '" & replace(request.querystring("email"),"'","''") & "' AND id = " & replace(request.querystring("id"),"'","''"))

... og det er det som databasen nrokker sig over.

Bortset fra det, så er det *mindre* sikkert at bruge id frem for at bruge password.

Der skal ' omkring strenge
Der skal # omkring datoer (i access)
Der skal  omkring tal <-- dvs ingenting
Strenge sikres mod sql injektion ved replace(teksten,"'","''")
Tal sikres mod sql injektion ved cint(tallet)
----
Så hvis id er et tal bør det være
Set rs = Conn.Execute("SELECT * FROM data WHERE email = '" & replace(request.querystring("email"),"'","''") & "' AND id = " & cint(request.querystring("id"))
----
Men hvis du bruger din databases autonummerering som id
Hvordan skal brugeren så selv kende dette id?
Det virker lidt underligt, så skal du først hive id´et ud jo?
eller er jeg gal på den?
Brugernavn og password plejer at være nok

Fint nu virker det :)

Skulle måske også indsætte passwordet så?
Nogen der kan gi en forklaring på denne streng, hvorfor så mange paranteser og kommaer osv.?

'" & replace(request.querystring("email"),"'","''") & "'

busschou >> Stregen udsendes til brugerne via et nyhedsbrev

syntaksen er
Replace(tekst der skal udskiftes i, det som skal udskiftes, det der udskiftes med)
Såå når du laver en
replace(brugernavn,"'","''")
Så bliver alle enkelt stående ' udskiftet med dobbelte ''
Det gør at access ikke risikere at modtage sql kommandoer

Stregnen kanndeles lidt op sådan her (dog ikke på selve ASP-siden - kun her):

replace(
request.querystring("email"),
"'",
"''"
)

Det den gør er kortsagt at den erstallet alle forekomster af ' med dobbelt-'.

obhat >> om man som bruger kender sin email og id, eller sit brugernavn og kodeord, det er vist et fedt :o) Det er jo to tjek uanset hvad og kun den aktuelle bruger burde kende dem

Grunden til denne kodestump er for at give baskal sikring imod en hacker-teknik som kaldes SQL-injection.

ikke at vi skal skændes om 30 point men du får da gerne et svar af mig ;o)

Antag at jeg var bruger på dit site. I mit tilfælde ville din SQL-sætning kunne se sådan ud:

"SELECT * FROM data WHERE brugernavn = 'nielle' AND password = 'Wjkr4dc34W'"

Antag nu at jeg havde onde hensigter med din side. I dette tilfælde kunne jeg forsøge mig med at indtaste noget andet end nielle som mit brugernavn, f.eks.:

hacker' OR 1=1;

Hvis dette indsættes råt i din SQL sætning bliver det til:

"SELECT * FROM data WHERE brugernavn = 'hacker' OR 1=1;' AND password = 'Wjkr4dc34W'"

... og da alt efter ; betragtes som en ny SQL-kommando, er dette det samme som:

"SELECT * FROM data WHERE brugernavn = 'hacker' OR 1=1;"

Vupti, så har jeg en SQL sætning som udtrækker *alle* posterne i tabellem.

Denne teknik, ”SQL-injection”, virker bl.a. fordi at jeg kan få lov til at indsætte et '-tegn uden at der bliver taget nogen modforholdsregeler. Ved at erstatte ' med '' eliminers denne trussel.

SQL-injection er nok hackernes 1. angrebsvej når de vil ind på et website.

og det er så den harmløse udgave
prøv indsætte
hacker';Drop Table;
Så får du
"SELECT * FROM data WHERE brugernavn = 'hacker'; Drop Table; AND password = 'Wjkr4dc34W'"
hvorved hele din tabel slettes :o/
Så derfor :o)
Når du laver cint på tal så er det samme årsag for at sikre at det rent faktisk er et tal
Der findes flere måder at beskytte sig på men jeg vil mene at som begynder tager de to metoder her højde for det meste

Jeg må sige, at jeg er rystet over hvor let det rent faktisk er.
Som jeg ser det, ved jeg ingenting, der er vist rigtig meget at lære endnu?

Men vil det sige at jeg er ret sikker med denne her:
Set rs = Conn.Execute("SELECT * FROM data WHERE brugernavn = '" & replace(request.querystring("brugernavn"),"'","''") & "' AND password = '" & replace(request.querystring("password"),"'","''") & "'")

Og hvordan er det så med MyQSL databaser?

Den sikrer dig okey vil jeg mene
Det er et monster emne, det kan undgåes ved at bruge parametre i stedet
Hvilket jeg ingen erfaring har med
Men det kan du vist læse om på w3schools.com under ADO et sted hvis det er
Mht til mysql så ved jeg ikke hvordan det forholder sig når man benytter asp, jeg vil tro det er det samme som gælder i og med det er i asp du opbygger din sql streng

Den ser helt pæn ud.

Der er heller ikke noget specielt mht. MySQL databaser. SQL injection er en rimelig bred angrebsvinkel overfor alle typer af SQL-databaser.

Og selv de bedste kan glemme en validering hist og pist. Da den ny Eksperten var i beta havde admin overset en ... where id=x

x blev ikke valideret, og data kunne trækkes ud af andre tabeller. F.eks. brugernes password :o

Tak for jeres svar :)
nielle >> et svar.. så er der også et par point herfra.

ang parametre har jeg som sagt ingen erfaring
Men arne_v har lavet et eksempel her, til evt inspiration :o)
http://www.eksperten.dk/spm/624614

Det kræver vel også et eller andet sted, at man kender placeringen af databasen?
Men gennerelt kan man måske sige, undgå at sende strege ud til request.querystring og isteden holde alle data på serveren beskyttet med session, eller er det heller ikke sikkert?

Det er svært at sige hvad der er helt sikkert
Hvis du sidder på tråløst netværk og det ikke er beskyttet så kan jeg fange din sessions unikke cookie på din computer og derved få adgang til den side du er på..sååå
Men jo
Jeg undgår som regel Get i mine forms og nøjes med Post
Men igen, så kan man simulere en form på sin egen hjemmeside som sender til din side
Så uanset hvilken metode du benytter dig af bør du lave en replace på strenge og et tjek på tal _inden_ du sætter ind i databasen, og det altså _hver_ gang du ved en bruger måske kan have dårlige hensigter :o)

Svar :^)

Takker og points :)