mboost-dp1
Problemer med RSS-feed
Jeg er igang med at lave en blog, og på den har jeg dette RSS-feed:
http://index.wep.dk/blog/rss.xml
RSS-feedet validerer fint, så det burde være i orden.
Hvis man åbner feedet i IE og trykker på links virker det fint nok, men hvis jeg abonnerer på det i Google Reader og trykker på links får jeg denne fejl:
http://index.wep.dk/stuff/rss-fejl.jpg
Min tabel hedder bare "webindex", så hvorfor prøver den at finde "webindex.referer" lige pludselig?
Som man kan se i adresselinjen, så er URL'en rigtig nok. Dvs at hvis man prøver at kalde den samme URL i et andet faneblad, så virker det fint nok:
http://index.wep.dk/blog/lorem-ipsum-1/
Nogen der har et bud på hvad der kan være galt?
http://index.wep.dk/blog/rss.xml
RSS-feedet validerer fint, så det burde være i orden.
Hvis man åbner feedet i IE og trykker på links virker det fint nok, men hvis jeg abonnerer på det i Google Reader og trykker på links får jeg denne fejl:
http://index.wep.dk/stuff/rss-fejl.jpg
Min tabel hedder bare "webindex", så hvorfor prøver den at finde "webindex.referer" lige pludselig?
Som man kan se i adresselinjen, så er URL'en rigtig nok. Dvs at hvis man prøver at kalde den samme URL i et andet faneblad, så virker det fint nok:
http://index.wep.dk/blog/lorem-ipsum-1/
Nogen der har et bud på hvad der kan være galt?
Det er jo åbenbart noget på din server, der reagerer på om der er en Referer i request-headeren, og så tilføjer ".referer" til tabelnavnet.. Hvorfor den gør det kan jeg jo ikke sige, da jeg ikke kan se din serverside-kode..
Jeg fik også fejlen da jeg klikkede på dine links(undtagen det til .jpg-filen.. Det er jo nok statisk..)
Når man klikker på et link på en hjemmeside, så sender browseren adressen på den side man kom fra med i forespørgselen.. Det kaldes Referer i request-headeren..
Jeg fik også fejlen da jeg klikkede på dine links(undtagen det til .jpg-filen.. Det er jo nok statisk..)
Når man klikker på et link på en hjemmeside, så sender browseren adressen på den side man kom fra med i forespørgselen.. Det kaldes Referer i request-headeren..
#2: Mange tak for opklaringen. Det er helt klart noget med den referer. Det hjalp at sætte dette ind øverst i scriptet:
Men det er jo ikke en så holdbar løsning bare at slette den referer. Min kode til at forbinde til databasen og tabellen ser sådan her ud:
Jeg går ud fra det er der fejlen opstår?
$_SERVER['HTTP_REFERER'] = "";
Men det er jo ikke en så holdbar løsning bare at slette den referer. Min kode til at forbinde til databasen og tabellen ser sådan her ud:
function con_db() {
$link = mysql_connect("localhost", "user", "password");
mysql_select_db("webindex");
}
con_db();
Jeg går ud fra det er der fejlen opstår?
Jeg har bygget feed'et ud fra denne tutorial:
http://www.carronmedia.com/create-an-rss-feed-with...
Men som jeg forstår det så ligger fejlen ikke i mit RSS-feed, men på selve siden som linker peger på. Ellers ville fejlen vel ikke opstå bare ved at klikke på dette link?:
http://index.wep.dk/blog/lorem-ipsum-1/
Men jeg ved det ikke :)
http://www.carronmedia.com/create-an-rss-feed-with...
Men som jeg forstår det så ligger fejlen ikke i mit RSS-feed, men på selve siden som linker peger på. Ellers ville fejlen vel ikke opstå bare ved at klikke på dette link?:
http://index.wep.dk/blog/lorem-ipsum-1/
Men jeg ved det ikke :)
Fejlen fundet!
Jeg havde noget kode liggende som gemmer den originale referer i databasen:
Når den bliver deaktiveret virker alting som det skal.
Jeg kan dog ikke helt gennemskue hvorfor det får min kode et andet sted på siden til at kalde den table i databasen som den gør?
Jeg havde noget kode liggende som gemmer den originale referer i databasen:
// Store referer in database
if(!empty($_SERVER['HTTP_REFERER'])) {
$referer = $_SERVER['HTTP_REFERER'];
$needle = "index.wep.dk";
$pos = strpos($referer, $needle);
if($pos === false) {
$date = date("d/m-Y - H:i");
$query = mysql_query("insert into referer (referer, time) values ('$referer', '$date')") OR DIE(mysql_error());
}
}
// Store referer in session
if($_SESSION['referer_noted'] !== 1) {
$_SESSION['referer'] = "$referer";
$_SESSION['referer_noted'] = 1;
}
Når den bliver deaktiveret virker alting som det skal.
Jeg kan dog ikke helt gennemskue hvorfor det får min kode et andet sted på siden til at kalde den table i databasen som den gør?
Så blev mysteriet løst. Jeg har simpelthen slettet den tabel der hedder "referer" engang i sidste uge, uden overhovedet at tænke over at der var noget kode der brugte den. Og når man ikke lige sørger for at ens side virker når man kommer via en referer, så kan der faktisk gå lidt tid før man opdager det :/
Men jeg skal jo bare lære at læse de fejlmeddelelser ordentligt... Så går det noget nemmere.
Men I skal allesammen have mange tak for hjælpen!
Men jeg skal jo bare lære at læse de fejlmeddelelser ordentligt... Så går det noget nemmere.
Men I skal allesammen have mange tak for hjælpen!
Windcape (7) skrev:Det kunne være rigtig morsomt at sætte sin HTTP_REFERER til følgende:
"'; DROP TABLE referer --"
... og så besøge din side ;-)
Ej, det er da ikke pænt at hacke en side når man får kildekoden foræret :)
Men nu vi er ved snakken, så har jeg i min nye kode lavet alle bruger inputs således:
$name = $_POST['name'];
$name = mysql_real_escape_string($name);
$name = strip_tags($name);
Vil det hjælpe på det eller skal der lidt mere til?
Prepared statements tvinger dig til at lade database serveren håndtere det korrekt på samtlige parametre.
Ved brug af mysql_real_escape_string kunne du "glemme" en.
Desuden giver mysql_real_escape_string jo ikke særlig meget mening på numre, og andre ikke-string typer.
Ved brug af mysql_real_escape_string kunne du "glemme" en.
Desuden giver mysql_real_escape_string jo ikke særlig meget mening på numre, og andre ikke-string typer.
#escape vs prepared
Prepared statement er bedre end escape string af 2 årsager:
1) Det er nemt at verificere at man har husket det alle steder.
Hvis man generelt bruger prepared statement og man søger i sit projekt efter
mysql_query
mysqli->query
(og et par stykker mere)
og ikke finder noget, så ved man at den er OK.
Hvis man bruger escape string skal man manuelt checke hele kdoen for at se om alt input i SQL sætninger har været en tur gennem mysql_real_escape_string eller mysqli->real_escape_string.
Så man sparer mange timer ved at bruge prepared statement.
2) Escape string har problemer med multi byte tegnsæt.
mysql_real_escape_string og mysqli->real_escape_string bruger default tegnsæt når de escaper.
Meget snu personer har opdaget at man ved brug af multi byte tegnsæt bl.a. kinesisk kan snige SQL injection igennem escape processen.
Prepared statement er bedre end escape string af 2 årsager:
1) Det er nemt at verificere at man har husket det alle steder.
Hvis man generelt bruger prepared statement og man søger i sit projekt efter
mysql_query
mysqli->query
(og et par stykker mere)
og ikke finder noget, så ved man at den er OK.
Hvis man bruger escape string skal man manuelt checke hele kdoen for at se om alt input i SQL sætninger har været en tur gennem mysql_real_escape_string eller mysqli->real_escape_string.
Så man sparer mange timer ved at bruge prepared statement.
2) Escape string har problemer med multi byte tegnsæt.
mysql_real_escape_string og mysqli->real_escape_string bruger default tegnsæt når de escaper.
Meget snu personer har opdaget at man ved brug af multi byte tegnsæt bl.a. kinesisk kan snige SQL injection igennem escape processen.
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund