Avatar billede martinb82 Nybegynder
03. december 2012 - 18:24 Der er 17 kommentarer og
1 løsning

Send password med POST variabel

Hey

Jeg er igang med at kode en "modtager side" til en form, som en kunde skal kode. Dvs. kunden har lavet en tilmeldingsformular, og han vil så kunne indsætte feltværdierne i min database. For at han kan få lov til det, vil jeg selvfølgelig gerne have at han sender brugernavn og adgangskode med, som gemte felter, samt jeg gerne vil kunne checke om POST'en kommer fra den rigtige IP, når dataene så kommer til min resultatside.

Det duer dog ikke at han bare indtaster brugernavn og password i "hidden" felter, da disse jo bare kan læses i source'en..

Er der nogen der kan pege mig i retning af hvad jeg skal gøre :)
Avatar billede claes57 Ekspert
03. december 2012 - 18:35 #1
en tilmelding (navn, email) som sender en mail til bruger med adgangskode (datolåst til kun at virke i fx 24 timer).
Link i email kører så bruger til login-side #2 (med låst brugernavn), hvor resten kan indtastes (+ skift til personligt valgt adgangskode).
Avatar billede martinb82 Nybegynder
03. december 2012 - 20:26 #2
Hmm, nej det fungerer ikke rigtigt lige i min situation, men tak for ideen :)
Avatar billede claes57 Ekspert
03. december 2012 - 20:45 #3
hvad med at acceptere det, og så sende en mail retur til kunde om, at siden er tilrettet, og hvis ikke der svares på mail indenfor 12 timer, så opdateres koden ikke. Ellers opdateres koden så snart mail-accept er modtaget retur til dig.
Mail kan så have et kundenummer+sidenavn med krypteret (find selv på noget kode her - ikke md5)
Avatar billede martinb82 Nybegynder
03. december 2012 - 20:52 #4
Det passer ikke til min situation :) Min kunde har en formular på sin side, hvor han vil kunne taste kunder ind i sit system fra, bare ved at udfylde en formular, og trykke send. Der skal ikke være yderligere arbejde i det, ellers er det nemmere på den gamle måde.
Avatar billede claes57 Ekspert
03. december 2012 - 21:13 #5
https ?
Avatar billede martinb82 Nybegynder
03. december 2012 - 21:22 #6
Altså protokollen https? Hvordan skal det implementeres i praksis? Skal der laves noget om i koden, for at variablene kodes?
Avatar billede olebole Juniormester
03. december 2012 - 22:51 #7
<ole>

Alle http-adresser skal rettes til https - og så skal du have et gyldigt certifikat på serveren. Ellers er der intet mystisk.

Men jeg forstår ikke, hvordan det kan være, at din kunde kan indtaste sine kunders passwords. Hvor kender han dem fra?

/mvh
</bole>
Avatar billede martinb82 Nybegynder
03. december 2012 - 23:23 #8
Hej olebole

Okay, så kom jeg da så meget tættere :) Min kunde kender ikke sine kunders password (eller det gør han faktisk, men kun indtil de selv har rettet dem til), det password han kender, er det password jeg indtil videre sender med i formularen, for at finde ud af om han har tilladelse til at skrive i databasen. Og det er sådan set bare det password jeg ikke ønsker at man skal kunne se i kildekoden til hans formular.

Jeg tester i øjeblikket simpelthen bare med dette:

<input type="hidden" name="password" value="pass">

Men det kan jo ses i kildekoden :)
Avatar billede olebole Juniormester
04. december 2012 - 00:33 #9
"det password han kender, er det password jeg indtil videre sender med i formularen, for at finde ud af om han har tilladelse til at skrive i databasen."

Det lyder som et paramount sikkerhedshul!  =8-O

Nu kender jeg jo ikke applikationen i enkeltheder, men det, du fortæller, lyder svært bekymrende. Prøv at forklare lidt mere præcist, hvad der sker
Avatar billede martinb82 Nybegynder
04. december 2012 - 00:42 #10
Hehe, nej nej, han sender ikke password'et til databasen med :) Han sender bare et "godkendelses-password" med i en post variabel, og hvis det så stemmer overens, med hvad vi har stående i modtager-filen, kobler vi op til databasen.

Hans formular med navn, adresse, postnr, og en masse andet (på hans egen host) -> POST -> vores php side, der læser post variablene og putter dem i en db (efter de er checket for injection osv) (på vores egen server).

Giver det mening?
Avatar billede olebole Juniormester
04. december 2012 - 01:09 #11
Måske, jeg er speciel tung i dag, men jeg forstår stadig ikke rigtig, hvad det er, du skal bruge  =)
Avatar billede martinb82 Nybegynder
04. december 2012 - 01:21 #12
Det er nok mig der er dårlig til at forklare :)

Han har en formular på sin side. Den formular har action="min side på min server" method="post". Lige nu, har  han så nogle inputs i den formular. Bl.a. har han et tekst felt der hedder navn, og et der hedder email. De to felter vil han gerne have ind i min database, som ligger på en anden server. For at få lov til at indsætte de to felter i min database, har han også to hidden felter i sin formular, der hedder brugernavn og password. Når han trykker "submit" bliver POST variablene sendt til min "min side på min server". Hvis de to "hidden" felter stemmer overens med de værdier der står i min PHP kode på "min side på min server", starter jeg en PHP funktion, der tager hans $_POST variable (dvs. $_POST['navn'] og $_POST['email']) og indsætter dem i min database med en mysql_query funktion (fx mysql_query("INSERT INTO tabel...)). Derefter laver "min side på min server" en refresh til en side han har defineret, så han næsten ikke opdager at hans browser loader en side på min server.

Problemet er så udelukkende, at hvis man højreklikker på hans formular, og trykker på menupunktet "vis kilde", kan man se linien <input type="hidden" name="password" value="detteerhemmeligt">. Og det skal man jo helst ikke kunne, da man så ALT for let kan lave sin egen formular, som så kan indsætte "navn" og "email" i min database på min server.

Giver det mening nu? Altså det jeg vil, er at jeg vil have fjernet muligheden for at se "detteerhemmeligt" fra hans formular...
Avatar billede olebole Juniormester
04. december 2012 - 01:40 #13
For det første lyder det så følsomt, så du under alle omstændigheder skal bruge SSL (https). Derudover bør formularen ligge på din server, så du kan validere/kende din kunde på en session - og dermed også helt kan undgå at sende password til din kunde.

Det kan godt være, at svaret på det er "Det passer ikke til min situation", men så bør du måske overveje, om der kunne være tale om en designfejl.

Derudover bør du nok smide det gamle, forældede og usikre MySQL-API på lossepladsen og komme i gang med en mere tidssvarende databasekode: Prepared statements under PDO eller MySQLI. Så slipper du f.eks. for de tvivlsomme hacks mod SQL-injection, du uden tvivl gør brug af på nuværende tidspunkt - mysql_real_escape_string, and the like  =)
Avatar billede martinb82 Nybegynder
04. december 2012 - 09:37 #14
Tanken bag er sådan set, at dataenes følsomhed, og risikoen er relativt lille, så vi var klar på at overveje muligheden for at lave sådan en løsning. Men indtil videre har vi kørt med at kunderne lagde deres tilmeldingsformularer på vores server, og så bare inkluderede den på deres egen side. Det kunne godt være at vi bare skal holde os til det.

Det kunne da godt være at jeg skulle til at se på at opdatere mine 10 år gamle metoder :D Jeg tror lige at jeg prøver at kigge på Prepared statements, men jeg er egentlig bare vant til at lave tingene så de virker, uden at gå så meget op i metoden, bare det er hurtigt at lave og afvikle.. Men ja, jeg trækker en mysql_prep funktion med mig rundt på alle mine projekter :D

Lidt OT, men har du nogle gode sider du kan anbefale, hvor man kan følge med i hvad der sker i PHP/Mysql verdenen? Ud over eksperten ;) Jeg sidder og koder alene, og så kan man godt blive lidt fastlåst i gamle metoder..
Avatar billede olebole Juniormester
04. december 2012 - 14:21 #15
Det kræver en meget kritisk tilgang at finde valide/lødige/troværdige informationer om webudvikling på WWW. Steder som w3.org, php.net, developer.mozilla.org, msdn.microsoft.com, mysql.com og sitepoint.com er nogle af dem, jeg selv bruger. Derudover er der en del områdespecifikke bloggere, jeg mere eller mindre sporadisk følger. Udover selve udviklingsarbejdet går der meget let et par timer om dagen med at holde sig opdateret og udvikle sine kompetencer.

Hvad prepared statements under MySQLI angår, kan du evt. begynde med denne guide. Derudover vil jeg anbefale dig at kikke på PDO, som på nogle områder er endnu lettere at bruge. MySQLI- og MySQL-API'erne ligner bare hinanden lidt mere og er måske lidt lettere at komme igang med.

Og ja, jeg tror, det er en bedre løsning at lade dokumentet ligge hos Jer. I hvert fald bliver det lettere. Ellers skal du ud i at udveksle/vaildere tokens, hvilket kan indebære en del faldgruber.
Avatar billede martinb82 Nybegynder
05. december 2012 - 15:57 #16
Super, mange tak, jeg kigger mig lidt omkring på de sider du foreslog, og så vil jeg prøve at se om jeg kan finde nogle gode bloggere..

Og vi er kommet frem til at have siden liggende hos os selv, som vi har gjort indtil videre.

Smider du lige et svar?
Avatar billede olebole Juniormester
05. december 2012 - 20:48 #17
Ellers tak, jeg samler ikke point. claes57 plejer heller ikke at modtage point, så du lægger bare selv et svar og accepterer det. Derved lukkes tråden  =)
Avatar billede martinb82 Nybegynder
17. december 2012 - 19:26 #18
Okay, her er så svaret :)
Avatar billede Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.

Loading billede Opret Preview

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester