Hente en variable fra en settings fil

$user_id = $settings['user_id'];
$result = mysql_query("SELECT * FROM Click where folder='$user_id'");

Kan forstaa variablen til at kalde er '.$user_id.'

Men bruger jeg variablen faar jeg ikke noget fra databasen

$result = mysql_query("SELECT * FROM Click where folder='['$user_id']'");

Tusinde tak det virkede
kan du lave en svar traad saa du kan faa dine point

weeee :D :D :D :D

Prøv med min udgave :-)

:-)

En anden ting: hvilke tegn kan user_id bestå af?

Det er nemlig vigtigt, at man har styr på indholdet af sine variabler inden de indsættes i sådan en sql.

<ole>

Koden er forældet og alt for usikker. I dag bruger man ikke længere PHP's MySQL-API, som er alt for usikkert (fejlkonstrueret) og i mange situationer langsomt.

I dag bruger man (og det har man faktisk gjort længe) prpared statements under MySQLI eller PDO. Prøv at læse denne guide om MySQLI

/mvh
</bole>

alfametic and nummermetic characterts no special metics

Ole i det her tilfaelde var det kun til at vise links som var tildelt en user fra databasen. og koden er som du ser er det en genereret code.

og til et specielt admin panel der er password sikret med php og mysql system, til at vise nulstillings links maaanedligt.

Venlig Hilsen
Brian Olsen

Nej, det er det, der er hele pointen: Hvis du bruger gammeldags/forældet, er der ikke noget i din applikation, som er 'password sikret'. Det betyder ikke noget, hvad meningen med koden er 'i dette tilfælde'. Din applikation er en lækkerbidsken for enhver hacker-noob.

Det gamle MySQL-API er rystende usikkert, hvorfor det ikke længere bruges til ny kode - og langt de fleste steder er man godt i gang med at skrive gammel kode om til tidssvarende og sikker kode  *o)

En anden ting: Forbinder du til databasen med sammen bruger og password, når en bruger 'bare læser sider' på dit site - og når du administrerer sitet? I så fald har du også sat vand over til alvorlige sikkerhedshuller på dét felt

Ups ... der skulle stå: "Hvis du bruger gammeldags/forældet kode, er der ikke noget i din applikation, som er 'password sikret'"

vi bruger generet koder til alt og alle mysqldatabaser har password generet koder som er forskellige.

Pasword scriptet vi bruger er et script for sig selv som redirect til de andre sider hvor der er indsat en headder saa hvis ikke looget ind faar du bare en no access fil og bliver bedt om at logge ind.

Den user_id er ikke noget nogen kan bruge til noget den er kun til at liste nogle links fra databasen som er tildelt den enkelte user.
For at kunne liste kun de links der er relateret til brugeren, Saa click counteren kan taelle rigtigt.

Du kan jo proeve om du kan faa adgang til scriptet her: http://awc24h.com/click/HujAw8Ra/ , som du ser bruger jeg ogsaa generet coder til mappe structur, for ekstra sikkerhed.

Men for at give dig ret saa skal kode normalt laves opdateret,og det hyrer jeg mig normalt ud af , jeg er totalt newbee i script codning og finder som regel bare script og til passer dem til mit brug. Ligenu betaler jeg 390 $ om maaneden til mit main site, for codning og host af siden.

Tja ... $390 svarer til 2-4 udviklingstimer, så når hostingen er trukket fra, er der ikke meget tilbage til den månedlige udvikling/vedligeholdelse.

De ting, du nævner, ændrer ikke noget ved det, jeg skrev. At I bruger genererede passwords til jeres databaser, samt at disse har forskellige passwords, betyder heller ikke nødvendigvis noget for sikkerheden.

Det er stadig et faktum, at PHP's MySQL-API er usikkert og forældet. Du kan gøre, hvad somhelst 'for ekstra sikkerhed'. Når selve din databasekommunikation er usikker, er din applikation usikker.

Dine diger kan være 150 meter høje og 30 meter tykke. Hvis bare to meter i stedet består af en bræddevæg, har du sat vand over til en alvorlig oversvømmelse!  *o)

Det er ikke uden grund, at folkene bag PHP selv fraråder at bruge MySQL-API'et til ny kode og i stedet anbefaler prepared statements med MySQLI eller PDO.

Derudover er det ekstremt vigtigt, at den bruger, der logges ind i databasen med, kun har adgang til at udføre de nødvendige handlinger på databasen. Når en bruger bare skal læse dynamiske sider, må den MySQL-profil, der forbindes til databasen med, kun kunne udføre SELECT kommandoer - ikke INSERT, UPDATE, DROP, ALTER, el.lign.

Ja hvis skulle have en dansker til at udvikle og hoste saa vill jeg nok ikke kunne vaere med laengere. men nu bruger jeg Filipinske kraefter i min udvikling af siden saa jeg faar meget for mine penge.

Ville aldrig bruge et dansk website firma til at tage sig af min side, for dyrt, iforhold til alle andre lande pga af den hoeje skat i Danmark.

Det du siger der vil jeg kigge naermere paa, men som sagt,sa er jeg helt ny i kodning og bare at faa noget til at virke var svaert, jeg vil selfoelig laere alt hvad jeg kan, og forhaabentlig blive noget bedre til at programere php og mysql med tiden.

Tak for dine raad

Hilsen
Brian

Man kan også sagtens hyre billige kodere i Danmark - men de skriver også usikker og uprofessionel kode. Tidssvarende, sikker og professionelt skrevet kode koster penge. Og så er det med kode som med alt muligt andet: Lidt godt er bedre end meget skidt  *o)

Specielt, når du er ny i PHP/MySQL, kan det betale sig at begynde med MySQLI eller PDO med det samme. Så skal du ikke bruge tid og energi på at lære det to gange. Held og lykke med projektet  =)