Webkafeen

[AnaXyd]

Masse flotte guider der! Har prøvd ut litt nå, så vi får se hva browserne sier!

 

 

Jeg har et lite oppdrag til noen som kan Fraktguiden til Posten/Bring jeg! Nemlig å implementere denne inn i Wordpress e-shopen min (WP e-commerce). Dette er selvfølgelig lønnet arbeid. Send meg PM om interessert!

[MikkelRev]

Geocitizer!

 

Få alle nettsider til å se ut som de ble laget av en 13 åring i 1996.

http://wonder-tonic.com/geocitiesizer/

[JohnRichard]

Haha, good old times

[Anonym5656]

Heia Judofyr

 

http://blog.inspired.no/xss-vulnerability-on-twitter-com-760

[Matsemann]

Har du en link man kan lese normalt?

[AnaXyd]

Noen som vet åssen man lager css hacks til Chrome?

 

Til IE gjør man jo f.eks slik:

 

<!--[if IE 7]>

[Jesper Karsrud]

Hvorfor trenger du å lage hacks til Chrome? Da gjør du noe veldig feil i så fall... Kun IE som skjønner conditional comments uansett, dessverre....

[AnaXyd]

Æsj, har nemlig en liten margin/padding bug som kun oppstår i Chrome faktisk! Funker fett i IE og FF, men faktisk ikke i Chrome. Har aldri opplevd at Chrome har kranglet før, så dette var nytt for meg.

 

Da er det vel ingen andre muligheter enn å gå inn i koden og prøve ut noe annet da?

[Matsemann]

Du kan jo google "chrome padding bug" (evt. margin) og se om noen problem med løsninger ligner på ditt.

[Jesper Karsrud]

Sikker på at det ikke er Chrome som har en annen default padding enn de andre har da, som du ikke har nullstilt?

[MikkelRev]

Du kan vel bruke javascript for det?

Første googletreff: http://davidwalsh.name/detecting-google-chrome-javascript

[Jesper Karsrud]

Aldri, jeg mener ALDRI, target en spesifik nettleser etter user agent. Feature detection er veien å gå, noe annet er altfor lett å fake, og kan føre til dumme feil. Et feature detection-bibliotek det kan være nyttig å ta en titt på er Modernizr.

[mikk-]

Noen tanker om best practice for URL-er nå for tiden? Hva er moten?

 

Driver og pusler med et prosjekt og vurderer:

blupp.no/details/1337/ -- veldig lesbar

blupp.no/details/1337/tittelen-kommer-her/ -- lang, men god for SEO?

blupp.no/d1337/ evt bare blupp.no/1337 -- lett å huske/skrive fra tekst

 

*prøve å begynne å følge med litt på hva som skjer innen webutvikling igjen*

[melli123]

Noen andre som sliter med å laste opp bilder i wp 3.01?

 

Unable to create directory wp-content/uploads. Is its parent directory writable by the server?

Endret 7. oktober 2010 av Vegard Melsom

[AnaXyd]

Veldig viktig at du setter de riktige tilgangene på de rette mappene. Du kan prøve å lage uploads selv, og gi denne 777 tilgang.

[Bolson]

Veldig viktig at du setter de riktige tilgangene på de rette mappene. Du kan prøve å lage uploads selv, og gi denne 777 tilgang.

 

For guds skyld - gi aldri mapper under webroot tilgang 777. Om du da ikke vet at oppsettet er chrooted eller bruker suPHP. Mange påstår at 777 ikke er farlig, jeg har dessverre sett det motsatte (erfart det).

 

I utgangpunktet skal løsninger som WP, Drupal etc kunne lage mappen selv om tilgangen på mappenivå er 755. Dog har jeg opplevd webhotell som er litt rare på dette fordi de bruker delt eierskap - dvs at eier av mappene er ssh/ftp-brukeren og ikke webbrukeren. Webbrukeren (apache, www-data etc) er medlem av gruppen. Med 755 er det kun eieren av mappene som kan lage nye mapper eller laste opp filer til disse. Med 775 kan også gruppa gjøre det, og med 777 kan alle.

 

@Vegard Melsom: Problemet du har har også oppstått ved flyttinger og oppgraderinger av WP. Det ser ut som at WP lager seg "absolutte" referanser til mapper - og disse har i gitte tilfeller blitt feil.

 

Men jeg anbefaler at du går inn på serveren via shell (SSH), og så sjekker du rettigheter der. Om du forteller på hvilken plattform/webhotell du hoster WP er det også lettere å hjelp. Du kan også sende meg en PM om nødvendig. Ikke det at jeg kan så mye WP, men jeg kan en god del om brukerrettigheter (særlig på linux/unix).

 

Rettighetene i shell vil se slik ut om du bruker ls -l (forutsetter linux)

 

drwxr-xr-x 3 user group 4096 2010-06-25 18:05 default

 

drwxr-xr-x er det samme som 755

 

d står for directory/mappe

r står for lesbar

w står for skrivbar

x står for kjørbar

 

første tegn angir om det et mappe, symlink eller noe annet

tre neste forteller brukerens rettigheter

tre deretter gruppas rettigheter

tre siste er alle sine rettigheter (world)

 

drwxr-xr-x sier da som følger: dette er en katalog hvor brukeren kan lese, skrive og kjøre, gruppa og verden kan kjøre og lese.

 

Om du da lurer på hvorfor vi kan bruke f.eks 777 eller 775, så har det bare en oversettelse til binære tall. Forklart her.

 

Om du bruker shell og trenger å gi en mappe med undermappe utvidede rettigheter, så er det følgende kommando

 

chmod -R 777 mappenavn (personlig foretrekker jeg chmod -R ugo=rwx mappenavn). R står for rekursiv.

[melli123]

@ Bolson: takk for et utrolig bra svar, men må nok sette meg litt mer inn i det før jeg kan svare noe nærmere på det, men skal selvfølgelig prøve det du sier.

[AnaXyd]

Aj! Det må jeg si! Men hva kan skje om man gjør som jeg sa?

 

Og mener at dette står i installasjonsguiden til WP også, at man skal chmodde til 777?

 

Men uansett, det du sier er helt sikkert riktig! Interessant å høre.

[Bolson]

Aj! Det må jeg si! Men hva kan skje om man gjør som jeg sa?

 

Og mener at dette står i installasjonsguiden til WP også, at man skal chmodde til 777?

 

Men uansett, det du sier er helt sikkert riktig! Interessant å høre.

 

Jevnt over skjer det ikke noe galt - men i realiteten har du gitt alle og en hver skriverettigheter. Skulle da det være gitte sikkerhethull i den totale installasjonen (enten i WP, Apache eller andre steder) kan det at alle har skriverettigheter til en katalog medføre muligheter for å legge inn kjørbare skript etc.

 

Nå kjenner jeg i WP godt nok til å vite hvilke sikkerhetsmekanismer som finnes ellers. I TYPO3 som jeg bruker, og som også lagrer bilder etc i bestemte kataloger - er det klar sikkerhetspolicy å ikke anbefale chmodding til 777 for noen del av installasjonen. Men som jeg også skrev, enkelte webhotell har hatt/har oppsett som gjorde dette nødvendig. I dag bruker de fleste suPHP (suexec) som bør gjøre bruk av 777 helt unødvendig.

 

Å bruke chmodding til 777 som en normal og anbefalt løsning mener jeg ikke er tillitvekkende - normalt bør en løsning kjøre med strengere rettigheter.

[AnaXyd]

Så om man ikke har teken på Linux og SSH, så er 755 cmodden som er anbefalt?

 

Syntes det er dumt at enkelte guider sier at man skal chmodde til 777, når man i prinsippet ALDRI skal gjøre det? Men hvordan kan en tredjepart på lagt inn en script i en mappe på min server?

Endret 8. oktober 2010 av AnaXyd