Sla over naar de inhoud

Categorie: blog

Chili Publisher – Online Document Editor

Vorige week was ik bij het kick-off evenement ‘Plug in the power‘ van CHILI publisher 4.0. CHILI Publisher, een veelbelovend product van het bedrijf Chili Publish, is een online document editor. In tegenstelling tot de meeste desktop document editors, kan dit product geïntegreerd worden in een web applicatie. Dit zorgt er voor dat eind-gebruikers dezelfde functies kunnen uitvoeren als vergelijkbare desktop applicaties, maar dan in hun browser.

Door middel van de CHILI API is het mogelijk om tegen deze online document editor aan te programmeren. Dit biedt tal van mogelijkheden, voorbeelden hiervan zijn de Magento plugin Chili Publisher Connector of de website Tadaaz waar de online document editor is geïntegreerd in een Drupal website. Voor een van mijn klanten pas ik het Chili Publisher product ook toe in een Business-2-Business omgeving.

Bekijk onderstaand promo-filmpje over Chili Publisher, of kijk voor meer informatie op de website.

Deel dit viaShare on LinkedInTweet about this on TwitterShare on FacebookEmail this to someone
Leave a Comment

PDF-documenten genereren in Java of C#

In dit blog-artikel ga ik in op het automatisch genereren van PDF documenten in Java of C#. In het verleden heb ik voor een opdrachtgever met behulp van iTextSharp automatisch PDF-documenten gegenereerd. iTextSharp is een .NET port van iText, een open-source library geschreven in Java. De PDF-documenten werden on-the-fly gegenereerd op basis van dynamische gegevens die een klant had ingevoerd.

Een andere library geschreven in Java is PDFlib, ontwikkeld door PDFlib GmbH. Met PDFlib is het mogelijk om lege blocks in een PDF-document te vullen met dynamische content. Daarnaast is het met deze library ook mogelijk om PDF-documenten uit te lezen en samen te voegen.

Deel dit viaShare on LinkedInTweet about this on TwitterShare on FacebookEmail this to someone
Leave a Comment

Yii: performAjaxValidation()-bug en oplossing

In het verleden heb ik voor een project het Yii-framework toegepast om een sociaal platform te bouwen in PHP met een MySQL database. Het voordeel van het Yii-framework is dat er veel documentatie en veel extensies beschikbaar zijn. Het nadeel van het Yii-framework en de extensies is dat er soms bugs kunnen zijn die niet meer worden opgelost. Gelukkig is er dan nog het Internet waarop bugfixs geplaatst worden.

Ik heb bij het bovengenoemde project het Yii-framework toegepast in combinatie met de yii-user-management extensie. Op onze test-server met Apache werkte deze extensie naar behoren. Echter op onze productie-server met Nginx kreeg ik deze error-melding:  “Declaration of YumTranslationController::performAjaxValidation() should be compatible with that of YumController::performAjaxValidation()” bij de user/translation/admin-pagina. Op deze pagina zou normaal gesproken de vertalingen beheert kunnen worden.

Aangezien wij deze vertaal-functionaliteit toepaste bij onze website, heb ik gezocht naar een workaround voor deze bug. Ik heb deze workaround bij de bug-melding op Google Code toegevoegd als opmerking. Het bestaat uit het aanpassen van de volgende 3 methodes in YumTranslationController.php-bestand (modules/user/controllers):

  • actionUpdate
  • performAjaxValidation
  • loadModel

Door de methodes te vervangen door de methodes hieronder lijkt het probleem opgelost.


 

Deel dit viaShare on LinkedInTweet about this on TwitterShare on FacebookEmail this to someone
1 Comment

Free Bassel

Afgelopen weekend las ik het verhaal over Bassel Khartabil, een gerespecteerde open-source software ontwikkelaar uit Syrië. Deze ontwikkelaar heeft bijgedragen bij ontwikkelingen op het internet, onder andere door mee te werken aan het Aiki Framework-project.

Sinds 15 maart 2012 zit Bassel Khartabil vast na een golf van arrestaties in het Mazzeh-district van Damascus, zonder dat officiële instanties de familie op de hoogte houdt over de verblijfplaats. Al ruim een jaar is deze ontwikkelaar onvrijwillig verdwenen van de aardbol, zonder een legaal proces en zonder rechten die een vrij mens anno 2013 zou moeten hebben.

Als mede software ontwikkelaar kan ik iedereen alleen maar oproepen om de petitie te steunen die familie en vrienden hebben opgestart: http://freebassel.org/ 

Deel dit viaShare on LinkedInTweet about this on TwitterShare on FacebookEmail this to someone
Leave a Comment

SSH time-outs met Terminal op Mac OS

Ik had vaak een terugkerend probleem met betrekking tot ssh via de applicatie Terminal op Mac OS. De connecties werden regelmatig automatisch inactief na een korte periode zonder toetsaanslagen.

Gelukkig vond ik op deze blog van Irakli Nadareishvili een oplossing van dit irritante probleem. De oplossing bestaat uit een kleine aanpassing in /etc/ssh_config zoals beschreven in dit blog item, namelijk het toevoegen van onderstaande regels aan dit bestand:

Terminal moet wel opnieuw opgestart worden na deze wijzigingen.

Deel dit viaShare on LinkedInTweet about this on TwitterShare on FacebookEmail this to someone
Leave a Comment

Sites verhuisd naar Ooxe

Afgelopen week heb ik deze blog en de website van Streeksoft verhuisd naar hostingprovider Ooxe. Beide sites stonden eerst tijdelijk gehost bij Dreamhost, aangezien ik daar ook een account heb voor verschillende development omgevingen. Waar snelheid bij een development omgeving niet heel erg belangrijk is, is dit natuurlijk wel een belangrijk item bij productie omgevingen.

Voor Artist Network gebruiken we ook de diensten van Ooxe, ze hadden destijds een pakket samengesteld die precies aansloot bij onze behoeftes. Aangezien ik erg goede ervaringen heb met hun service, was de keuze snel gemaakt om ook mijn blog en Streeksoft-website bij Ooxe onder te brengen.

Deel dit viaShare on LinkedInTweet about this on TwitterShare on FacebookEmail this to someone
Leave a Comment

Magento en problemen met de snelheid

Vorig jaar heb ik voor een klant veel met het open-source e-Commerce Magento gewerkt. Magento is een uitgebreid systeem waarmee het mogelijk is om meerdere webshops te draaien binnen 1 Magento installatie. Vooral het feit dat zaken zoals de productenlijst of instellingen gedeeld kunnen worden tussen de webshops maakt Magento een sterk systeem.

Magento heeft echter ook een groot nadeel en dat is de snelheid, of beter gezegd; de traagheid. Het systeem kan soms aan de voorkant langzaam reageren en dat resulteert in een langere laadtijd van de pagina’s. Ook in de backend van het systeem kan het bij sommige acties traag reageren. Destijds ben ik bij deze klant begonnen met pogingen om de snelheid van Magento te verbeteren. Hieronder enkele tips daarvoor:

  • Installeer Magento niet op een shared hosting account, een VPS of dedicated server is beter.
  • Kies een server uit die voldoet aan de systeemeisen van Magento.
  • Probeer Nginx als webserver in plaats van Apache (vooral bij veel bezoekers op hetzelfde moment zou Nginx beter moeten werken).
  • Activeer Magento’s cache optie (via System -> Cache Management).
  • Deïnstalleer plugins die niet gebruikt worden.
  • Gebruik plaatjes die lossless gecomprimeerd zijn.
  • Mocht er veel wijzigingen aan de productinformatie zijn en de backend traag zijn, dan is het handig om via System -> Index Management het automatisch indexeren op handmatig te zetten. Door middel van cron jobs kan elke nacht het php-script indexer.php aangeroepen worden om te indexeren.
  • Repareer en optimaliseer op een rustig moment de MySQL database, en herhaal dit na enkele maanden (dit kan via phpMyAdmin).
  • Voor de gevorderden onder ons, probeer extra tools op de server te installeren en te configureren zoals APC, Memcached en Varnish.

Mijn ervaring is, dat het een verminderen van de traagheid een iteratief proces is van meten en de server configureren. De snelheid van de site valt handmatig te meten met Google Chrome en de Page Speed Monitor plugin. Vertrouw niet te veel op de Site Speed die bij Google Analytics staat vermeld; deze rekent namelijk alleen de gemiddelde laadtijd van bezoekers met nieuwe browsers.

Mochten deze tips niet helpen, het is altijd mogelijk om tips op andere blogs te bekijken, zoals de tips van Guido Jansen.

Deel dit viaShare on LinkedInTweet about this on TwitterShare on FacebookEmail this to someone
Leave a Comment

Casus: Joomla-hack en oplossing

Tegenwoordig worden op websites steeds meer standaard Content Management Systemen (CMS) zoals Joomla, WordPress en Drupal gebruikt in plaats van custom-made Content Management Systemen. Het voordeel hiervan is dat er legio plugin’s, thema’s en handleidingen beschikbaar zijn voor deze systemen. Het nadeel hiervan is dat dergelijke systemen ook aantrekkelijk zijn voor kwaadwillende hackers, omdat deze systemen door talloze mensen gebruikt wordt.

Kwaadwillende hackers richten zich vaak op oudere versies van deze systemen, omdat daarvan bijvoorbeeld beveiligingsfouten zijn ontdekt en gepubliceerd. Zo werd ik begin dit jaar door een bekende gevraagd om naar de beveiliging van zijn Joomla-website te kijken. Deze persoon kreeg vaak klachten van klanten dat ze tijdens een bezoek aan de Joomla-website werden doorgestuurd naar vreemde Russische websites, met als gevolg dat de anti-virus & anti-spyware programma’s alarm sloegen. Niet echt positief tegenover je (potentiële) klanten als ze dergelijke zaken meemaken bij het bezoek van je website.

Onderzoek probleem

Bij het horen van de problemen, vermoedde ik al dat de website slachtoffer was geworden van kwaadwillende hackers. Als eerste onderzocht ik welke versie van Joomla werd gebruikt op de website. Dit is simpel te achterhalen door de broncode van de website te bekijken. Bij de meta-tags staat een tag vermeld met als naam ‘generator’ en daarachter de versie, in dit geval Joomla! 1.5. Deze versie is gereleased in januari 2008, maar is tot en met maart 2012 ondersteund met updates [1]. Op dit moment, februari 2013, zijn de meest recente versies: 2.5 (januari 2012) en 3.0 (september 2012).

Vervolgens onderzocht ik welke bestanden als laatste aangepast waren. Al snel ontdekte ik dat de website sinds april 2010 niet meer was bijgewerkt. Des te meer het opviel dat er in oktober 2012 een bestand ‘post.php’ in de map ‘images’ was geplaatst met de volgende regel code:

Opvallend was ook dat pas met Kerst 2012 dit bestand gebruikt (of misbruikt) is om de volgende bestanden te bewerken: CHANGELOG.php, configuration.php, COPYRIGHT.php, CREDITS.php, index.php, index2.phpINSTALL.php, LICENSE.php en LICENSES.php. Aan deze php-bestanden was op de 1e regel van het bestand de volgende code toegevoegd:

Deze code kan tot leesbare code omgezet worden door gebruik te maken van een online Base64 decoder zoals base64converter.com. Dat resulteert in de volgende code:

Uit deze code valt af te leiden wat er gebeurt bij het aanroepen van een van de getroffen php-bestanden. Men wordt alleen doorgestuurd naar http://onotiw.dnset.com/ (inmiddels niet meer bereikbaar), als ze via een zoekmachine zoals Yahoo, Bing of Google de website bezoeken. Dit verklaart ook waarom de werknemers zelf geen last hadden van de hack; zij gingen altijd direct naar de website (zonder gebruik te maken van zoekmachines dus).

Oplossing

De oplossing voor deze Joomla-hack is redelijk eenvoudig. Verwijder het bestand ‘post.php’ in de ‘images’-map. Via dit bestand was het immers mogelijk om overige php-bestanden aan te passen. Wijzig daarna de getroffen bestanden en verwijder de toegevoegde (base64 encoded) code op de 1e regel. Nu zijn de grootste wijzigingen van de hack teruggedraaid, maar het beveiligingsgat is nog niet gedicht. Het is trouwens mogelijk dat een kwaadwillende hacker nog meer bestanden heeft aangepast dan beschreven in dit artikel.

Mijn mening over het beveiligingsgat is dat de hack voorkomen had kunnen worden door het Joomla CMS up-to-date te houden. Een veelgebruikt CMS ruim 2 jaar niet updaten is vragen om problemen, zeker als er verwijzingen naar Joomla 1.5 in de broncode op je website te vinden is. De gevolgen waren bij deze casus nog te overzien, maar het is vervelend als door zo’n simpele hack bijvoorbeeld de gegevens uit je klanten-database op Internet te vinden zijn.

Ook bij het gebruik van open-source Content Management Systemen geldt: voorkomen is beter dan genezen.

Elke maand controleren of uw CMS en bijbehorende plugins en thema’s nog up-to-date zijn is dan ook aan te raden bij het gebruik van open-source content management systemen. Als u ook vermoeden heeft dat uw website gehackt is en u komt er verder niet uit, dan kunt u altijd contact met mij opnemen.

  1. Joomla. (2013). In Wikipedia. Retrieved February 26, 2013, from http://en.wikipedia.org/wiki/Joomla
Deel dit viaShare on LinkedInTweet about this on TwitterShare on FacebookEmail this to someone
1 Comment

Nederlandse language-file voor Image CRUD

Voor sommige opdrachtgevers, maar ook bij eigen projecten, voeg ik open-source libraries toe aan applicaties om zo sneller tot een resultaat te komen. Daarnaast is het ook zonde om steeds het wiel opnieuw uit te vinden als dit wiel door de makers ervan (onder voorwaarden) gratis wordt aangeboden. Laatst heb ik bijvoorbeeld de libraries van Grocery CRUD en Image CRUD in combinatie met het CodeIgniter framework toegepast bij een project.

Grocery CRUD is een library waardoor het eenvoudig is om de basisoperaties Create, Read, Update en Delete uit te voeren op een tabel in een database. Image CRUD is een library van dezelfde ontwikkelaar om de basisoperaties ook uit te kunnen voeren met afbeeldingen. Bij beide libraries is het mogelijk om de taal te wijzigen door het gebruik van language-files; bestanden die de vertalingen van de teksten bevatten. Bij Image CRUD was er nog geen Nederlandse language-file aanwezig. Als dank voor het beschikbaar stellen van de libraries heb ik de Nederlandse language-file voor Image CRUD opgesteld. Deze is inmiddels toegevoegd aan de GIT-repository van Image CRUD, dus beschikbaar voor iedereen.

Als u interesse heeft om Grocery CRUD of Image CRUD bij uw projecten te implementeren, dan kunt u altijd contact met mij opnemen.

Deel dit viaShare on LinkedInTweet about this on TwitterShare on FacebookEmail this to someone
Comments closed