Hangt er een beetje vanaf hoe die widget werkt, mogelijk schrijft deze HTML waarbij dus ook een i-frame wordt gecreëerd, maar mogelijk pakt 'ie dus de afmetingen uit de style-tag of is deze op een of andere manier instelbaar via andere parameters. En misschien kun je zelfs de methode-van-integratie kiezen (inline via AJAX-calls of toch via een i-frame). Zou je even in de documentatie van deze widget moeten duiken, mits die er is.
Posts by FangorN
-
-
Hm, als ik in de broncode van de blogpagina kijk zie ik dat de breedte van de chat-widget 832 pixels is.
Als je vervolgens op "832" zoekt in het broncode-bestand van hierboven dan vind je deze terug onder widget id "HTML11".
Misschien als je het daar aanpast?
En op een soortgelijke wijze zou je kunnen proberen de andere i-frame widgets ook zo aan te passen.
Ik kan verder ook niet direct overzien hoe alle (widget)interacties verlopen.
Ook in je browser (o.a. in Chrome) kun je een tablet-view simuleren in developer modus (meestal onder de F12 toets als deze is geactiveerd, klik vervolgens op het mobiel/tablet icoontje om te schakelen tussen desktop en tablet/mobiele weergave). Daar zou je eens wat kunnen spelen met CSS-instellingen. Na een page-refresh of wegnavigeren zijn deze wel weg, dus even goed bijhouden wat je wijzigt om tot het gewenste / een gewenster resultaat te komen.
Het probleem met het verder uitontwikkelen van een mobiele versie als de desktop versie er al ligt is dat je dan meestal weer dingen moet gaan afbreken / uitkleden. Als een site o.a. voor mobiel wordt ontwikkeld dan wordt de mobiele variant meestal eerst gebouwd geloof ik ("mobile first") omdat het makkelijker is om daarna uit te breiden in plaats van de andere kant op te werken.
-
Klopt het (dus) dat de combinatie mobiel + i-frames voor problemen zorgt?
Een i-frame is in wezen een aparte site / venster in je site. Alles wat daarin gebeurt is ook letterlijk en figuurlijk begrensd door dit venster. Als je deze begrenzing wilt doorbreken zul je:
- ofwel tussen je site en het i-frame moeten communiceren,
- ofwel af moeten stappen van i-frames
In het eerste geval zijn er waarschijnlijk nog aanvullende randvoorwaarden, zo moeten het "parent frame" en het i-frame zich op hetzelfde domein bevinden en van hetzelfde protocol (http, https etc) gebruik maken anders zullen browsers dit om veiligheidsredenen niet (zomaar) toestaan.
Wanneer hier aan voldaan is dan zou je (theoretisch :p) met wat kunst- en vliegwerk via JavaScript vanuit het i-frame instructies kunnen geven om in het parent frame een filmpje te openen. Je hebt dan in principe de begrenzingen van het i-frame omzeild, maar aan andere kant, door de introductie van het i-frame veroorzaak je in zekere zin zelf deze beperkingen. Je bent dan dus ook min of meer oplossingen aan het verzinnen voor een probleem wat je zelf geïntroduceerd hebt.
Maar als ik hier echt buiten het kader zou denken (teehee) dan zou ik zeggen dat je op je site allerlei verschillende soorten content wilt laten zien waar je tegelijkertijd zelf de controle over wilt hebben. Wat je in wezen wilt is dus een dynamische website. En het liefst "uit één stuk" zodat je één document hebt waar alles in zit. Achter elke dynamische website steekt vaak een (server side) scripting taal waarmee je verschillende stukken functionaliteit kunt invoegen in een enkel document, maar dan moet je wel die mogelijkheid (en enige kennis) hebben natuurlijk.
Nu weet ik niet of de mate van vrijheid die je wilt in combinatie met wat je wilt echt goed of makkelijk haalbaar is op een medium als blogspot.com. Een andere mogelijkheid die ik eventueel zie is dat je via JavaScript dynamisch content inlaadt (met behulp van zogenaamde AJAX calls). Ook via die weg kun je in principe afstappen van het gebruik van i-frames maar rechtstreeks één document bakken + direct serveren zou natuurlijk een veel directere weg zijn.
Misschien zou je het ook als volgt kunnen zien: je wilt méér met je site en begint nu tegen obstakels te lopen. De vraag is dan: wil je om deze obstakels heen, wil je deze wegnemen (maar dan loop je wellicht tegen andere beperkingen van blogspot aan) en hoeveel moeite wil je hiervoor doen? Of wil je wellicht iets anders waarmee dit mogelijk wel makkelijk(er) kan? Denk bijvoorbeeld aan, ik noem maar een zijstraat, goedkope webhosting i.c.m. een wordpress pakket ofzo?
NB: persoonlijk, heb even door de broncode getuurd, vind ik dat de source al behoorlijk vol zit met allerlei (onnodige?) JavaScript. Als je hier aan gaat sleutelen wordt het misschien ook nodeloos complex(er) dus wat dat betreft zit je al met een redelijk grote erfenis van allerlei zut. Dat werkt niet fijn - het is een blok aan je been :/. Voor wat je wilt doen kan het volgens mij allemaal een stuk simpeler.
-
en kan het daardoor ook niet vergeten
Totdat je dit wel een keer doet :p. Het is gewoon wachten op een ongeluk.
Maar je uitleg is wel logisch kan het misschien beter op de plek zelf toepassen zodat het duidelijker is.
Het is gewoon vele malen consequenter. Plus je hoeft er dan gewoon niet meer over na te denken, dus het is ook gewoon stukken simpeler (ook een goed ontwerpprincipe: Don't Make Me Think). Escape waarden op het moment dat je deze in een context onschadelijk wilt maken. Maar niet vantevoren.
Als je gewoon deze laatste aanpak gebruikt weet je meteen wanneer iemand vergeten is een waarde te escapen, je hoeft dan niet eens de afweging te maken op grond van de inhoud van de variabele, escape gewoon altijd, maar dan dus wel op het goede moment :).
Hetzelfde geldt voor de context waarbinnen de waarde ontdaan moet worden van een mogelijk speciale betekenis: wat "speciaal" is hangt van de context af - deze hoeft ook niet altijd op voorhand vast te staan. Zou je dan zo'n variabele maar op voorhand dood moeten escapen voor alle mogelijke contexten? En wat dan als je een dump wilt doen naar een plaintext bestand, ga je dan weer alles un-escapen (denk aan "& amp;" enzo, ga je die weer terugvertalen naar "&"?). Je doet dan waarschijnlijk een hoop werk voor niets, werk waar je je later mogelijk mee in de vingers snijdt.
Ah well.
-
Wordt er iets gedaan aan de ogenschijnlijke stortvloed aan registraties van wat naar alle waarschijnlijkheid botaccounts zijn?
Om maar een greep te doen uit de (online) gebruikers die zich vandaag hebben geregistreerd:
1emmac972rb2
1jasminee912ta0
1miae24100to1
7madisonc7291gh2
9emmae512fh3
ahici
arehogen
Couringtonse5
Ricklesaq8
Schmiereres7
tomkdy142
block546fuVaak met eenzelfde of eenzelfde soort avatar (Super Mario gerelateerde karakters?).
Dan knalt deze site er tegenwoordig wat vaker uit. Begint deze te bezwijken onder de druk van requests van nepaccounts?
-
Data die in je systeem zit zou je niet als veilig moeten zien.
Stel dat, om wat voor reden dan ook, gebruikersnamen of andere teksten van een profield de input "</div>" toestaan. Als je dit vervolgens zonder escaping weergeeft ligt je layout in puin. En zo zijn er nog wel andere zaken denkbaar zoals AJAX-calls naar een externe site als jij een profiel bekijkt ofzo... Escape altijd output, tenzij je een speciale, en gedocumenteerde, reden hebt om dat niet te doen.
En om toch terug te komen op het voorgaande, vergelijk:
PHP$sql = "SELECT something FROM table WHERE condition='".$condition."'";De vraag is dan elke keer opnieuw: is $condition gevalideerd / veilig? Of beter gezegd: is dat een query die altijd het gewenste resultaat geeft? Iedereen die dat stuk code ziet zou zich dat af moeten vragen. Dat kost elke keer weer (interpretatie)tijd.
Vergelijk dit met:
PHP$sql = "SELECT something FROM table WHERE condition='".$db->escape($condition)."'";
Waarbij $db->escape() een shorthand is voor real_escape_string(). Het maakt in dat geval niet uit of $condition veilig was voor gebruik in een query of niet - de combinatie escaping-functie + quotes garandeert dit. Op een soortgelijke wijze zou je prepared statements kunnen gebruiken, ook dat is een methode om te waarborgen dat DATA niet als SQL geinterpreteerd kan worden (dit is in feite wat SQL-injectie mogelijk maakt).Het dilemma in het eerste fragment is dus altijd of escaping bewust achterwege is gelaten of per ongeluk is vergeten. Je introduceert hiermee twijfel. Als je gewoon consequent alles escaped is er NOOIT ruimte voor twijfel. Zodat je hier dan ook nooit meer over na hoeft te denken.
-
$ingame bevat de session user (escaped) zodat ik deze makkelijk overal kan gebruiken.
Oef. Ik weet niet of ik dat zou doen. Dit klinkt namelijk sterk als "escape on input". En escaping van data hangt af van de context. Waarvoor is dit (op voorhand) ge-escaped dan? Voor SQL? Voor HTML? Voor alles?
Indien het de bedoeling is dat data ontdaan moet worden van een mogelijk speciale betekenis in een bepaalde context, dan doe je dat tijdens het gebruik van deze data in die context. Het is zaak dat je output escaped.
Nu is het nogal ongewis dat $ingame ge-escaped is (en voor welke context precies). Als je dit altijd consequent doet tijdens het gebruik dan is dat compleet ondubbelzinnig en hoef je niet elke keer na te denken of na te gaan of dit wel het geval was. Nu moet je elke keer nadenken "is dit veilig of niet". Maak het jezelf makkelijk en escape gewoon consequent alle DATA in je SQL. Of maak gebruik van prepared statements ofzo, in welk geval je beter PDO kunt gebruiken want prepared statements in MySQLi zijn nogal een gribus.
Trouwens, de enige informatie die een sessie qua user data hoeft te propageren is in principe het user id. Alle actuele user data zou elke page request opnieuw berekend moeten worden om ervoor te zorgen dat deze altijd up-to-date is. Die zou je dan in een user object kunnen stoppen waar je vervolgens aan refereert bij gebruik in je code, zoals je nu ook al doet met via $gebruikerinfo.
Ik weet niet hoeveel user data er nu in de sessie zit? Als je op die manier gebruikersgegevens tussen requests propageert introduceer je een synchronisatieprobleem. Immers, elke keer dat er iets in de user data verandert zou je dit moeten updaten in je sessie. En stel nu dat een admin rechten van een (andere) gebruiker intrekt, wanneer wordt dit dan gereflecteerd in de sessie van die gebruiker zelf? Je kunt namelijk niet rechtstreeks andermans sessie inhoudelijk wijzigen.
Bedien je van het motto: filter input, escape output, en je komt een heel eind. Mits je weet wat dit inhoudt :p.
Escape-on-input is heel vaak geen goed idee, maar zoals met alles zijn er ook uitzonderingen. Denk bijvoorbeeld aan "session flash messages". Stel dat je na het bijwerken van een artikel "bladibla" iemand direct redirect naar het overzicht van artikelen, maar dat je wel op een of andere manier een terugkoppeling wilt geven dat het artikel succesvol is gewijzigd. Deze informatie zou je tijdelijk in (een subarray van) je sessie kunnen stoppen waarin het bericht "artikel 'bladibla' succesvol bijgewerkt" staat. Je weet in dat geval dat dit bericht in de HTML-context gebruikt gaat worden, en je wilt niet dat je complete pagina breekt als je voor de gein </div> in je titel zet ofzo. Dus in dat geval is het geoorloofd om op voorhand output te escapen. Maar dit is dus een uitzondering op de regel.
Als je niet op voorhand weet in welke context data gebruikt gaat worden heeft het ook geen zin om te escapen en is het ook niet verstandig om deze data op voorhand voor alle mogelijke contexten onschadelijk te maken. Dit kan zelfs fouten in de hand werken zoals het bovenstaande artikel mooi illustreert :).
-
Ah, een klassiek voorbeeld van een gebrek aan ondeelbaarheid van (database-)operaties.
Dit heeft niet zozeer te maken met de manier van programmeren (deze doet er echt niet toe) maar meer met hoe je omgaat met je database. Je hebt hiervoor echt een soort van locking mechanisme nodig en idealiter gebruik je hiervoor transacties. Jammergenoeg worden (database-)transacties niet ondersteund door MyISAM.
Ik weet verder niet wat voor applicatie dit betreft (mafia game?) maar meestal hebben deze alle kenmerken van een "administratief" systeem - een database met een veelvoud aan tabellen met daartussen allerlei verbanden.
Wat dat betreft snap ik sowieso niet waarom je daarvoor ooit MyISAM zou willen gebruiken omdat er met die engine geen onderlinge afstemming tussen tabellen kan plaatsvinden. Je kunt dan eigenlijk met geen goed fatsoen verwachten dat alle data in die tabellen (onderling) kloppend is en (onderling) kloppend blijft. Alle data hangt letterlijk als los zand aan elkaar. Voor een administratief systeem ben je veel beter af met InnoDB. Die heeft namelijk al deze voorzieningen (transacties, foreign keys et cetera) wel.
Wat natuurlijk ook niet meehelpt is dat je op verschillende manieren refereert aan het saldo contant geld. Je hebt $gebruikerinfo->contant, een property van een of ander object? en users.contant. En dan zit het user id blijkbaar in $ingame, die zou ik dan eerder verwachten in $gebruikerinfo->id ofzo. Ik heb een onderbuikgevoel van spaghetticode.
Dan speelt er mogelijk nog het volgende: je refresht de pagina waarschijnlijk niet direct, anders zou dit minder snel (maar nog steeds, het is geen remedie) voor problemen zorgen, dus waarschijnlijk ben je tegelijkertijd een of ander formulier of andere data aan het verwerken terwijl je vrolijk een pagina aan het uitdraaien bent. Ben ik een beetje warm? Je bent dus waarschijnlijk zogenaamde "state changes" on-the-fly aan het uitvoeren wat uit algemeen oogpunt van programma-ontwerp een heel slecht idee is.
Betreft dit legacy code of ben je dit op dit moment aan het ontwikkelen?
-
@darkshifty die wordt ook aangehaald in het artikel (eerste item) waar ik hierboven naar linkte.
-
-
Het is ook niet zozeer wat je allemaal nodig hebt, maar ook wat je al intrinsiek bezit. Wanneer je bepaalde persoonseigenschappen hebt kan dit je helpen en ook sterken in je keuze.
Misschien nog het belangrijkste is een onderzoekende aard. Heb je bijvoorbeeld al eens gezocht op jouw eigen vraag "wat maakt een web developer vandaag de dag?". Dit is nou niet bepaald een uniek probleem, meerdere mensen hebben zich dit ongetwijfeld afgevraagd. Heb je bijvoorbeeld wel eens een webpagina bekeken en hebben gedacht: "Hee, ik vraag mij af hoe ze dit programmatisch / visueel voor elkaar hebben gekregen", waarna je met Ctrl-U de broncode ging doorspitten. Programmeren is in wezen het oplossen van (abstracte) puzzels.
Daarnaast helpt (dus) ook het vermogen om abstract te denken. Een programmeertaal is nou niet bepaald een spreektaal, maar beide stellen je in staat om een verhaal te vertellen, en op den duur kun je code ook als zodanig lezen.
Iets wat je in dit alles ondersteunt is tevens een nette werkhouding. Afhankelijk of je meer de creatieve of de technische kant uit wilt kan dit belangrijker of minder belangrijk zijn maar eigenlijk is het altijd wel goed om zorg te dragen voor wat je doet, in het groot, maar ook in het klein. Zoals spelling en zinsopbouw. Zo start je dit topic met "Beginnend webdevolper met vragen". Dat maakt bij mij nou niet bepaald een sterke indruk. Alsof je dit topic op meerdere plekken hebt neergeplopt in de hoop dat iemand je ergens een goed idee geeft wat te doen en je een richting geeft om in te lopen, maar uiteindelijk zul je zelf dit idee moeten vormen, het is immers jouw toekomst. Je moet ook zelf de handvaten hebben of ontwikkelen om deze keuzes te maken.
Ook zou ik niet alles op één paard inzetten, tenzij je echt de diepte in wilt met één (of enkele) bepaalde techniek(en). Dus tot slot is het je eigen maken van nieuwe technieken en methoden een pre. En dat wordt weer gevoed door een onderzoekende aard. Als je deze niet hebt, kleine kans dat je ver buiten je eigen vertrouwde gebied dingen gaat uitproberen. Dit is verder niet heel erg, maar beperkt mogelijk wel je eigen potentieel.
-
het werkt toch niet
Het oplossen van een probleem begint bij de analyse van het probleem. Je zult ons echt meer moeten vertellen over de foutmelding(en), het ongewenste gedrag van het systeem waarin dat resulteert, en het gedrag wat je had verwacht.
En ook de stappen (voor reproduceerbaarheid van het issue) die tot deze toestand leidde. Hierbij kun je ook gesterkt worden in je gelijk dat er inderdaad ongewenste dingen misgaan als je hierbij kunt aantonen dat je de procedure (voor wat je ook precies aan het doen was) hebt gevolgd. Aan de andere kant, mogelijk heb je ergens de getreden paden verlaten en ben je in een verse hoop gaan staan :).
Je kunt niet van ons verwachten dat als jij zegt "het werkt niet" dat wij dan direct zoiets hebben van "oh, dan moet je dat en dat doen".
Zo werkt dat (ook) helaas niet.
---
Misschien een schot voor de boeg: er staat: Access denied for user 'id10454959_db'@'2a02:4780:bad:f00d::8'
Dat lijkt op een IPv6 adres. Biedt het systeem hier uberhaupt ondersteuning voor? Of werkt deze uitsluitend met IPv4 adressen? -
Nu we het toch over begrijpend lezen hebben.
en ze willen later ook (met een jaar of 5) meer doen in de ict
kinderen van vijf jaar
"Met een jaar of 5" (in een jaar of 5) is niet, althans niet per definitie, hetzelfde als "op dit moment 5 jaar oud".
-
@tigermaffia niet nodig om je als banaan te gedragen, forums zijn er om je te helpen, maar als er onzin wordt gepost dan kun je verwachten dat mensen hier op reageren; om dan vervolgens je kont tegen de krib aan te gooien door het topic leeg te gooien, hier bereik je weinig mee
@Ferhat.Remory je hebt gelijk, waarom zou je hier nog aandacht/moeite aan besteden
@AarClay -
waarom kan ik niet gewoon een gebruikersnaam en wachtwoord invullen om in te loggen?
Nou, wat zou daar het nadeel van zijn? Dan zit je ledenbestand in een mum van tijd vol met botaccounts.
Denk eraan datbde source ouder is dan 5 jaar.
Dit heeft waarschijnlijk niet zozeer met tijd te maken, maar meer met de ervaring die de programmeur(s) toenertijd had(den). De principes die je zou moeten hanteren om spam en bots buiten te houden zijn in deze tijd volgens mij niet echt veranderd.
-
Webmensen, Webfanaat, Scriptfreaks, PHPfreakz (PFZ) en het gevorderde PHPexperience
Geen vermelding voor sitemasters? :p
Maar tegenwoordig heb je ook StackOverflow. Daardoor zijn heel veel sites ook minder populair geworden. Bijna elke vraag die je in Google gooit, wordt beantwoord door Stack Overflow.
Uitermate geschikt voor de knip-en-plak generatie die enkel geïnteresseerd is in instantane genoegdoening. Dit is een van de redenen waarom communities aan het uitsterven zijn: men wil enkel een direct antwoord op een informatievraag, en liefst meteen een complete oplossing, het gaat niet (langer) over het proces van het vinden van een oplossing. Het antwoord met de hoogste score is ook niet altijd de "beste" oplossing, en neemt ook niet altijd het (onderliggende) probleem weg (wat ook vaak zelf gecreëerd is).
Daarnaast wordt er ook voorbij gegaan aan het inspecteren van een juiste aanpak. Jammergenoeg wordt dit ook gevoed door forums die enkel een rechtstreeks antwoord geven op een rechtstreekse vraag, terwijl, ik zou haast zeggen in 9 van de 10 gevallen, het enige antwoord waar de vragensteller het meest bij gebaat is "Je aanpak is verkeerd." is.
Ik heb verder niet echt specifieke sites waar ik permanent op zit, behalve wellicht ictscripters en phphulp. Als ik informatie wil hebben over een onderwerp dan gooi ik dit in de zoekmachine. De vragen die mensen hebben zijn namelijk zelden uniek of nog nooit eerder gesteld. Nagenoeg altijd is iemand anders al ergens tegenaan gelopen en/of heeft een oplossing verzonnen voor een bepaald probleem.
Het is ook aan te raden om verschillende bronnen te raadplegen over eenzelfde onderwerp, dus in dat opzicht is het niet erg zinvol om je te beperken tot het handjevol websites waar je normaal op zit.
-
Ictscripters is zo inactief als het maar zijn kan.
Een forum is zo actief als zijn leden.
-
by the way:
Heb je ob_start(); ... staan in je script?
Ik ben een (groot) voorstander van het (correct :)) gebruik van output buffering, maar als dat wordt gebruikt om "headers already sent" of soortgelijke foutmeldingen onder het tapijt te vegen dan zit je pagina-opbouw niet snor he :).
Vaak houdt dat in dat functionaliteit die geen onderdeel uitmaakt van, noch onderdeel zou mogen zijn van het genereren van output (het uitpoepen van de HTML-pagina) dwars door deze output heenloopt. Bijvoorbeeld dat je nog even een formulier-verwerking tussendoor fietst met een headertje en dat je daarna in één ruk doorgaat met het weergeven van het desbetreffende formulier in een HTML-pagina.
Dit is dan weer een indicatie dat je de verschillende acties die een verzameling code/functionaliteit verzorgt niet goed hebt gescheiden. Denk bijvoorbeeld aan een contact- of inschrijfformulier waarbij de verschillende acties altijd min of meer de volgende zijn:
- weergave van het formulier (eventueel met kanttekeningen van fouten en hoe deze te verbeteren wanneer het verwerken mislukte)
- verwerking van het formulier (inclusief sturen van mail, database-(trans)acties et cetera)
- een bedankpagina o.i.d.
Dit alles zou je echt moeten vangen in gescheiden/gecompartimenteerde acties. Als dit niet gebeurt dan is dit een recept voor onleesbare spaghetti-code, en daarmee is het fundament van je applicatie al heel erg wankel.
-
Als je wilt dat mensen door een backend gaan ploeteren is het misschien handig dat je een (tijdelijk) account aanmaakt zodat men dingen kan testen?
-
Waar zijn de exit;'s na de header('Location: ...')'s?
Het hele script wordt op deze manier gewoon afgedraaid.Kun je ook negatieve bedragen doneren? Want is_numeric() accepteert ook negatieve bedragen? Je zou dus theoretisch geld kunnen stelen van je clan, de ultieme crime? :p
Kun je ook meer donaties doen (tegelijkertijd) dan dat je geld hebt? Want geen van dit alles locked tabellen/kolommen? Noch staat dit alles in een transactie?Misschien ook handig om eerst de hele validatie te doen (of zoveel mogelijk), en dan de vervolgacties op je database.
Ayyy.
