Raar bugje in Chrome

[Verwijderd]

Ik ben een soort van notitie systeem aan het maken in html5/css3 in context met jquery. Nu loop ik tegen een raar bugje aan. Ik zet de inhoud in textareas en input boxen, die disabled zijn. Deze inhoud is namelijk aan te passen als je op een knopje drukt. Alleen nu doet chrome raar, en kun je de notite div naar links en omhoog/beneden scrollen als je probeert het input fieldje te scrollen. Iemand hier bekend mee?

Voorbeeldje:
<-knip->

[ Voor 6% gewijzigd door Verwijderd op 10-05-2012 18:37 ]

[bartbh]

Ik kan je probleem niet reproduceren? Of misschien begrijp ik je probleem niet goed. Maar als ik je voorbeeld bekijk in Chrome (18.0.1025.168 m), zie ik geen scrollbalken en kan dus ook niet scrollen.

[Verwijderd]

Het probleem is dat zodra je de text in het blauwe/oranje balkje selecteert, je die text rond kan slepen in de notite zelf, en daarmee scrollt de notitie naar boven, beneden of naar de zij kant.

[bartbh]

In IE8 doet-ie nog veel gekker als je gaat schuiven door te klikken op de tekst ipv de rand. Kun je het niet anders oplossen? Maak er gewoon statische tekst van en als je wilt bewerken vervang je de tekst door een textarea/textbox en dan kun je de titel aanpassen. Het draggen van statische text gaat in Chrome in ieder geval wel goed, wat ik zo snel heb kunnen testen.

[Verwijderd]

Ja, dat is ook wel mogelijk. 't zou veel makkelijker zijn als het wel zou werken. Dan maar Inputs genereren zodra je het wil aanpassen.

[RobIII]

Even iets anders: Je pagina is vatbaar voor XSS én SQL injection

[Verwijderd]

RobIII schreef op donderdag 10 mei 2012 @ 17:43:
Even iets anders: Je pagina is vatbaar voor XSS én SQL injection

Weet ik, tis ook maar iets wat tussen vrienden wordt gedeeld. We gaan binnenkort beginnen met een gezamelijk project, en daarom maak ik dit notitie systeem, zodat we overal onze notities kunnen bekijken e.d.

Normaliter zou ik eesrt zowiezo checken met regex wat er in wordt gevoerd, sanitizen, htmlentities dr op enzo voordat ik het weg schrijf.

[ Voor 12% gewijzigd door Verwijderd op 10-05-2012 18:39 ]

[RobIII]

Verwijderd schreef op donderdag 10 mei 2012 @ 18:37:
Weet ik, tis ook maar iets wat tussen vrienden wordt gedeeld. We gaan binnenkort beginnen met een gezamelijk project, en daarom maak ik dit notitie systeem, zodat we overal onze notities kunnen bekijken e.d.

Dat is geen reden om daarom bescherming tegen SQL injection / XSS maar links te laten liggen Je moet jezelf aanwennen dit altijd te doen. Doe je dat niet dan ga je, daar kun je gif op innemen, het een keer vergeten te doen wanneer je wél te maken hebt met mensen buiten je eigen vriendenclubje. En wie zegt dat je dit project over X-maanden misschien wel niet publiek wil gooien? Ga je dan nog eens alles nalopen (met 't risico 1 dingetje over het hoofd te zien?) of gooi je 't dan open op hoop van zegen?

Verwijderd schreef op donderdag 10 mei 2012 @ 18:37:
Normaliter zou ik eesrt zowiezo checken met regex wat er in wordt gevoerd, sanitizen, htmlentities dr op enzo voordat ik het weg schrijf.

Neen, neeeen, néééééén!

htmlentities en consorten gebruik je in de presentatielaag, niet om SQL injection te voorkomen En je wil de teksten niet "met htmlentities" opslaan. Wat nu als je een keer een PDF'je wil maken van een notitie? Kun je die entities er weer uit gaan slopen. Data sla je "rauw" op (maar wel correct escapen als je querystrings gaat knutselen; beter nog: gebruik gewoon Parametrized Queries!) en ga je pas door htmlentities (of andere escaping voor het betreffende doel (PDF, zip, Excel, RTF, CSV, whatever)) halen wanneer je weet wat 't doel is. Je projectje is nu nog "HTML only" maar wie weet groeit 't uit tot iets leuks waar je later een plakboek van wil gaan maken in PDF vorm. Escaping is enkel-en-alleen maar zinnig in context en in dit geval dus in je presentatielaag. Die weet de context immers; wat je in je DB stopt hoort los te staan van je context.

Aan een notitie valt weinig te sanitizen (hooguit lengte van de strings lijkt me); dat doe je (bijv.) voor een geboortedatum (in veel gevallen is een geboortedatum van voor 1900 bijvoorbeeld een rood vlaggetje; je zult niet snel een gebruikersaccount hebben van gebruikers die 100+ jaar oud zijn om maar wat te noemen) of een bestelling van 4e32 flessen melk is niet erg zinnig. Dat is sanitizen. En een regex gebruik je om bijv. te controleren of een postcode in een zinnig formaat is ingevuld (mits je weer weet welk land en bijbehorend postcode formaat... etc.); je wil niet regexen gebruiken om "verboden tekens" uit strings te slopen.

Linkje voor je

[ Voor 41% gewijzigd door RobIII op 10-05-2012 18:56 ]