[ALG/.NET] belang leesbare url's icm met database

[PhoneTech]

De meeste database driven websites die hier gemaakt worden met dynamic content heeft meestal niet echt begrijpelijke url's

aantal voorbeeldjes:
http://www.asp.net/Forums...spx?tabindex=1&ForumID=16
Programming

Een leek heeft geen idee wat hij moet verwachten als hij deze URls ziet.

Ik heb een tijdje met Zope gewerkt, en daar was dat helemaal opgevangen. Elk object is via de url aan te spreken...

Dan krijg je bijvoorbeeld
http://gathering.tweakers.net/forum/programmingwebscripting/
http://gathering.tweakers...ngwebscripting/topicnaam/

Vooral bij websites die voor het grote publiek worden gemaakt, zijn de leesbare urls in mijn ogen best belangrijk.

Nu heb ik wel een idee hoe je dat kan doen op een database driven website.
Door gewoon een custom 404 pagina te schrijven en die 404 pagina kijkt wat voor een url het is, haalt deze uit elkaar, en redirect naar de juiste contenthandler

Naar mijn idee is dat niet echt een nette manier om die dingen te doen.

Hoe staan jullie tegenover leesbare urls? Dat het beestje bij de naam genoemd wordt en niet per nummer?

Welke technieken kan ik dan gebruiken om dit te doen in ASP.NET?

[Ramon]

topicNAMEN in urls lijken me niet echt handig..... Wordt denk ik traag, en de topicoverzichten zoals active topics worden ook een stuk groter, en onoverzichtelijker met %20's erin enzo.

[whoami]

3. Prevent Cross-site Scripting
Cross-site scripting vulnerabilities are Web-specific issues and can compromise a client's data through a flaw in a single Web page. Imagine the following ASP.NET code fragment:
<script language=c#>
Response.Write("Hello, " + Request.QueryString("name"));
</script>

How many of you have seen code like this? You may be surprised to learn it's buggy! Normally, a user would access this code using a URL that looks like this:
http://explorationair.com/welcome.aspx?name=Michael

The C# code assumes that the data is always well formed and contains nothing more than a name. Attackers, however, abuse this code and provide script and HTML as the name. If you typed the following URL
http://northwindtraders.c...name=<script>alert('hi!');
</script>

you'd get a Web page that displays a dialog box, saying "hi!" "So what?" you say. Imagine that the attacker convinces a user to click on a link like this, but the querystring contains some really nasty script and HTML to get your cookie and post it to a site that the attacker owns; the attacker now has your private cookie information or worse.
There are two ways to avoid this. The first is not to trust the input and be strict about what comprises a user's name. For example, you could use regular expressions to check that the name contains only a common subset of characters and is not too big.

MS security tips

Zie ook dit topic: [rml][ Alg] Safe code[/rml]

[PhoneTech]

Okok...Dat was ook een voorbeeldje...Maar er zijn genoeg voorbeelden te vinden wanneer het wel gewenst is om leesbare urls te hebben...En dan vooral marketingtechnisch

[Janoz]

Het probleem is eigenlijk meer het volgende:
Je wilt niet bij elke pagina aanroep de boel op deze manier door gaan geven. Een nummertje is veel sneller. Je kunt natuurlijk een combinatie van beiden gebruiken (linken naar 'onduidelijke' url's en 'duidelijke' wel accepteren), maar hoe maak je dan bekend dat mensen ook de duidelijke url's kunnen gebruiken?

Daarnaast kun je het natuurlijk veel te ver doorvoeren. Wat wil je bijvoorbeeld doen waneer 2 topics hetzelfde heten? Waneer er rare tekens in de url voorkomen (spatie is OOK een raar teken)? imho worden de url's er dan al helemaal niet duidelijker op.

[Ramon]

whoami schreef op 08 november 2002 @ 14:15:


[...]

MS security tips

Zie ook dit topic: [rml][ Alg] Safe code[/rml]

volgens mij is dat niet het onderwerp van dit topic. Dat soort regexpses moeten standaard in elke pagina zitten die informatie van de gebruiker verwerkt lijkt me

[PhoneTech]

Janoz schreef op 08 november 2002 @ 14:17:
Het probleem is eigenlijk meer het volgende:
Je wilt niet bij elke pagina aanroep de boel op deze manier door gaan geven. Een nummertje is veel sneller. Je kunt natuurlijk een combinatie van beiden gebruiken (linken naar 'onduidelijke' url's en 'duidelijke' wel accepteren), maar hoe maak je dan bekend dat mensen ook de duidelijke url's kunnen gebruiken?

Daarnaast kun je het natuurlijk veel te ver doorvoeren. Wat wil je bijvoorbeeld doen waneer 2 topics hetzelfde heten? Waneer er rare tekens in de url voorkomen (spatie is OOK een raar teken)? imho worden de url's er dan al helemaal niet duidelijker op.

We gaan er wel even vanuit dat per container alleen maar unieke textid's voorkomen!

Probeer het ook eens van niet programmeurs kant te bekijken...

[Janoz]

Ik probeer de voordelen naast de nadelen te zetten.. imho wegen de voordelen namelijk helemaal niet op tegen de nadelen. Daarnaast zul je extra beperkingen op bepaalde dingen moeten leggen die in het andere geval niet nodig zijn. Hierdoor beperk je je gebruikers meer dan dat je ze extra functionaliteit biedt.

Een manier waarop het wel werkt is bijvoorbeeld de manier van www.php.net. Zet er de functie naam achter en je krijgt automatisch het stuk uit de handleiding. Bestaat de functie niet? Dan wordt er een search uitgevoerd op dat woord. In dat geval is het wel erg nuttig. Dit komt ook vooral omdat de titel niet speciefiek voor dat stukje is. Een link als www.blaat.nl/hier_titel_nieuwsbericht heeft weinig nut omdat je het stuk al gelezen moet hebben wil je uberhaupt enige notie van de titel hebben. Aan de andere kant zou een www.blaat.nl/laatste_column of www.blaat.com/nieuwste_strip weer wel intresant zijn.

[Verwijderd]

Natuurlijk zijn zulke URL's veel mooier! Dus als dit mogelijk is,... graag!

En daarnaast biedt het vele voordelen zoals security. Een hacker zal toch eerst proberen andere id's in je querystring te zetten. Maar goed, dat valt altijd wel af te vangen (dus doe dat ook!).

Echter, alleen namen in de URL heeft ook nadelen zoals hierboven al ergens beschreven. Je URL kan veel langer worden. Effe gek gezegd: kijk eens in msdn.microsoft.com. Daar word je ook knetter van die lange URL's. Maar goed, daar wordt dan ook een document via een boom-structuur opgehaald.

Maar wat als je dat niet hebt en bijvoorbeeld oorspronkelijk een lijst van docs (database-genummerd van 1 tot 900 o.i.d.) wilt kunnen tonen. Heb je dan 900 verschillende namen nodig?
Nee. Je kunt best met PostBack werken, in plaats van id's. Dus een lijst van docs wordt gepresenteerd en a.d.h.v. jouw klik op een doc wordt ie onder water omgezet naar id, terwijl je URL heel netjes blijft. Geen gezeik met id's in de URL, maar ook geen mogelijkheid meer om direct te linken naar een bepaalde pagina.

Tsja, als je het mooi doet, is dit een oplossing. Toch geeft dit in eerste instantie wat problemen voor developers... En wie zijn belangrijker, developers op klanten...? (tricky one...).

Oh ja, wij zijn zelf bezig met ISAPI-filters. Ook nog een idee...

[PhoneTech]

> kick >/ ^

[ACM]

PhoneTechnician schreef op 08 november 2002 @ 14:20:
We gaan er wel even vanuit dat per container alleen maar unieke textid's voorkomen!

Probeer het ook eens van niet programmeurs kant te bekijken...

Zet die eerste regel es tegenover de tweede
Van niet-programmeurs zou je niet mogen eisen dat ze een nette unique, conform-destandaard zijnde, url intikken.
Als je perse zo'n mooie url wilt ondersteunen.

Dus geen unieke tekst, geen gedoe met gekke tekens (wat niet zomaar kan, want dat moet omgezet worden naar %20 voor spatie enzo).
Wat ik meer afvraag is trouwens je motivatie waarom het belangrijk is dat je url's leesbaar zijn.
Imho is het wel zinvol de url's kort te houden (ivm met copy&pasten in forums en andere plaatsen), maar is het minder zinvol de boel netjes leesbaar te maken.
Je loopt dan vanzelf tegen allerlei conversie problemen op, waarvan het niet uniek zijn en het bevatten van gekke tekens denk ik de lastigste zijn.


Wat je hier op GoT nog deels kan doen is bijvoorbeeld de unieke afkorting van een forum pakken.
Dus /forum/pw/ ipv jouw voorbeeld. Er moet iig altijd een unieke conversie mogelijk zijn (tenzij je een zoekstring aan het intikken bent ofzo natuurlijk ) lijkt me, met simpele karakters (zelfs geen spaties) en niet te veel tekst.

[tijn]

Bij ASP.NET kun je prima 'mooie' urls maken. Zoek maar eens op httphandler.

[Annie]

Volgens mij willen gebruikers helemaal niet mooie url's onthouden. Gebruikers worden vaak al doodmoe van het onthouden van alleen een domeinnaam.
Een pagina moet gewoon zo opgebouwd worden dat vanuit de homepage in een beperkt aantal stappen (afhankelijk van het soort site) naar de juiste info genavigeerd kan worden. Dan heb je ook geen rechtstreekse, mooie url's nodig.
Wanneer meteen naar een specifiek onderwerp gesprongen moet worden zijn daar zoekmachines voor of searchengines op de eigen site.

Zoals al aangegeven is het misschien voor sommige onderdelen van je site wel interessant om daar een rechtstreekse link naar te hebben. Daarvoor kan je dan subdomeinen gebruiken of 'mooie' url's (404, redirects, virtual dirs, multiviews, enz). Maar alles? Voor mij (als gebruiker) mag je je energie iig ergens anders in steken.

2 cent armer

[PhoneTech]

Voor de personen die nog enigzins geintresseerd zijn in dit onderwerp, ASP.NET heeft een standard url rewriter er in zitten...

Dus het kost niet veel moeite om dit te implementeren...

Hier is de URL http://www.codeproject.com/aspnet/URLRewriter.asp