The roads I take...

KaiRo's weBlog

März 2024
123
45678910
11121314151617
18192021222324
25262728293031

Zeige die letzten Beiträge mit "PHP" gekennzeichnet an. Zurück zu allen aktuellen Beiträgen

Populäre Tags: Mozilla, SeaMonkey, L10n, Status, Firefox

Verwendete Sprachen: Deutsch, Englisch

Archiv:

Juli 2023

Februar 2022

März 2021

weitere...

19. Juli 2023

Integration eines Magento-2-Webshops mit FreeFinance und selbstgebautem Warenmanagement

In den letzten paar Monaten habe ich (mit einem Kollegen) ein neues Unternehmen unter dem Namen Trade Post 47 aufgebaut. Während wir es uns als eine kleine Raumstation im Orbit eines schönen Planeten vorstellen, wird es für die meisten Menschen als Handelsunternehmen für Science-Fiction-Merchandise gesehen werden, mit einem Online-Shop sowie Ständen bei Veranstaltungen wie lokalen Comic-Cons in Mitteleuropa, vor allem in Österreich. Für alle, die mehr erfahren wollen, haben wir eine komplette Seite über uns auf unserer Shop-Website erstellt.
Bild Nr. 23537

Um unsere Produkte zu verwalten, die wir von verschiedenen Anbietern (manchmal das gleiche Produkt über verschiedene Anbieter) erhalten, sowie unsere Bestellungen zu planen und zu verwalten, habe ich ein internes, benutzerdefiniertes Warenmanagement in meinem eigenen PHP-Framework bzw. CMS CBSM (das zum Beispiel auch für dieses Blog verwendet wird) aufgebaut. Zum Großteil fiel die Entscheidung dafür aus Bequemlichkeit, nachdem ich dieses System sowieso betreibe und warte und ich einige Datenbanktabellen benötigte, inkl. passender Benutzeroberfläche für die Verwaltung unserer Waren, Anbieter und mehr (sogar Conventions, auf denen wir Stände betreiben möchten).

Andererseits ist der öffentliche Shop (wie Sie es bemerken können, wenn Sie sich die Website ansehen) eine Installation von Magento 2 (d.h. die Open-Source-Version von dem, was heute "Adobe Commerce" genannt wird). Wir haben uns für dieses System entschieden, weil wir eng mit MCO Shop zusammenarbeiten, einem lokalen CB-Funk- und Elektronikgeschäft, und dort bereits zuvor diese Software auf den Servern lief, die wir mitverwenden und das Wissen bereits da ist, wie damit gearbeitet wird, die Upgrades ausführt werden und das System gewartet wird. Schließlich hilft es beim Aufbau eines neuen Unternehmens immer, wie in so vielen Lebensbereichen, wenn man einige Ressourcen und Wissen mit anderen gemeinsam nutzen kann. Für unseren Teil, habe ich zuerst das Magento-Theme angepasst, um den Shop "Weltraum-ähnlicher" aussehen zu lassen, vor allem mit einem dunklen statt hellen Hintergrund. Sobald das gut genug funktionierte, musste ich immer noch jene Produkte aus meinem selbstgebauten Warenmanagement, die wir tatsächlich bestellt haben, in diesen Magento-Shop bekommen. Anfangs habe ich dafür eine große CSV-Datei erstellt und in den Shop importiert habe, aber es war klar, dass wir auf lange Sicht eine feinkörnige Lösung brauchten, die Einträge einzeln hinzufügen bzw. aktualisieren kann.

Zusätzlich, wann immer wir Stände auf unseren "Außenmissionen" auf Veranstaltungen/Conventions betreiben (oder wann immer wir sonst etwas persönlich verkaufen), verlangt das österreichische Recht die Verwendung eines Registrierkassensystems, das strengen Regeln befolgt und entsprechend zertifiziert ist, damit von Seiten der öffentlichen Verwaltung sichergestellt werden kann, dass wir korrekt unsere Steuern abführen. In diesem Bereich haben wir uns für die integrierte Lösung unseres Buchhaltungssystems entschieden, die auch online als Web-Service läuft, eine spezialisierte österreichische Lösung namens FreeFinance. Und natürlich braucht die Registrierkasse auch eine vollständige Liste der Produkte und Preise, die wir zunächst auch mit einer CSV-Erstellung und -Import gelöst haben, in Erwartung einer detaillierteren Lösung nach unserem ersten großen Auftritt auf der Austria Comic-Con Anfang Juni.
Bild Nr. 23538

Zur Abrundung wollten wir auch schön gestaltete Rechnungsdokumente in FreeFinance für alle Online-Shop-Bestellungen generieren, die nicht über die Registrierkasse bezahlt wurden, und in Zukunft möchten wir den Online-Shop automatisch auf Waren aufmerksam machen, die auf Veranstaltungen verkauft werden, so dass sie für Online-Käufe aus dem verfügbaren Lagerstand entfernt werden.

Um dies zu erreichen, habe ich mir die APIs angesehen, die sowohl Magento als auch FreeFinance bieten, und baute Verbindungen auf diese vom eigenen internen System auf, auf das ich vollen Zugriff habe und das für die Bereitstellung der Warendaten sowieso erforderlich ist. Ich fand heraus, dass die FreeFinance API relativ einfach und gut dokumentiert ist und die Authentifizierung über OAuth2 durchführt, von denen ich bereits durch andere Projekte einige Kenntnisse hatte (und Code für den Zugriff darauf), einschließlich einigem Code, der bereits im CBSM-System zur Durchführung von Logins verwendet wird. Magento dagegen ist eine andere Baustelle: sein Produktkatalog-Funktionsumfang ist viel komplexer, und ebenso die API dazu. Außerdem gibt es keine gut strukturierte kollektive Dokumentation, die erklären würde, was verschiedene Dinge bedeuten oder was vorzugsweise auf welche Weise getan wird (oft gibt es mehrere Wege zum gleichen Ergebnis) - Im Endeffekt resultiert die Arbeit meist im Einschalten des Entwicklermodus, so dass eine Swagger/Open-API-Benutzeroberfläche auf der Installation verfügbar ist und dann in Herumprobieren und im Internet herumsuche, was wie funktionieren könnte und welche Wert was heißen könnte. Darüber hinaus erfolgt die Authentifizierung über OAuth1, was komplizierter ist als sein Nachfolger, und wofür den ich keinen bereits bestehenden Code hatte, obwohl ich auf Code aus dem Tutorial aufbauen konnte. Da wir Magento selbst auf der Serverseite betreiben, konnte ich leichter mit Dingen herumprobieren, als bei FreeFinance, einem gehosteten Dienst, wo ich Zugangsdaten von ihrem Team anfordern musste. Aber FreeFinance gab uns Zugang zu einem Testsystem, während wir für Magento aus verschiedenen Gründen nur ein Live-System und kein Staging-/Test-Umgebung haben, so dass wir beim Testen nicht sehr viel "herumspielen" können.

Im Endeffekt habe ich ziemlich viel Code für all diese Fälle geschrieben, der einfachste Teil war und aktualisiert sicherlich die Kasse mit unseren Produkten, die einzige leichte Komplikation dort war Kategorien hinzuzufügen, wenn nötig. Um Produkte in den Shop zu bringen, musste ich alle möglichen Dinge respektieren, wie das Erstellen und Verwalten konfigurierbarer Produkte, Werte zu einigen Attributen anzulegen, Hochladen von Bildern, Verwalten von Kategorien und mehr. Und die merkwürdige Struktur der Magento-API, die viel detailliertere Aktionen als der CSV-Import-Weg erfordert, macht dies manchmal noch komplizierter - aber es funktioniert jetzt und ich kann einfach ein Produkt im Warenmanagement hinzufügen oder ändern und spätestens am nächsten Tag sind sowohl der Shop als auch die Registrierkasse mit den Änderungen aktualisiert (ich kann die Jobs auch früher auslösen, wenn benötigt). Für die Erstellung der Rechnungsdokumente konnte ich einige Dinge auf einem make.com "Blueprint" von FreeFinance aufbauen, aber zum einen möchten wir keinen bezahlten Drittanbieter-Service verwenden, wenn wir dies selbst automatisieren können, und zum anderen haben wir einige Einschränkungen und Spezialitäten unsererseits auch dabei (wie Rechnungen nur zu generieren, wenn Zahlungen direkt im Online-Shop gemacht wurden und nicht persönlich über die Registrierkasse). Ich bin dort auch auf einige Kuriositäten gestoßen, wie dass die Magento-Bestellungs-API manche Datensätze mehrmals enthält, oder wir haben zunächst eine Dokument-Layout-Vorlage verwendet, die nicht unterschiedliche Mehrwertsteuersätze unterstützt (was wir allerdings benötigen) - aber das funktioniert jetzt auch. Die umgekehrte Variante, Registrierkassen-Einkäufe im Online-Shop zu reflektieren, steht immer noch auf meiner Liste, aber ich habe jetzt einen guten Plan, wie ich das erledigen kann, und einige Zeit bis zu unserer nächsten großen "Außenmission", bei der dies wichtig sein wird.

Alles in allem war es eine ziemlich interessante Erfahrung, und nachdem ich mich jetzt mit der Arbeit mit diesen Systemen und APIs wohlfühle, bin ich mir sicher, dass ich werde auf lange Sicht mehr mit ihnen machen werde - und unser Trade Post 47 wird hoffentlich auch weiter wachsen und daher in Zukunft zusätzliche Anforderungen haben. Wenn ihr Entwickler seid und Fragen zu einigen Details habt, könnt ihr mich gerne kontaktieren - und wenn ihe solche Systeme selbst betreibt und einen Entwickler benötigt, der diese in ähnlicher Weise anpassen kann, bin ich auch gerne bereit, diese Dienste anzubieten!

Von KaiRo, um 00:18 | Tags: API, FreeFinance, Magento, merch, PHP, science fiction, Shop, Trade Post 47 | keine Kommentare | TrackBack: 0

11. Juli 2023

Integrating Magento 2 Shop With FreeFinance and Custom Merchandise Management

In the last few months, I have been building up a new business called Trade Post 47. While we envision it as a little space station in orbit of a nice planet, to most people it will be a science fiction merchandise trading company, with an online shop and booths at events like local Comic-Cons in Central Europe, especially in Austria. If you want to learn more, we have put up a complete page about us on our shop website.
Image No. 23537

To manage our products, which we get from different vendors (sometimes the same product via different vendors) as well as plan and manage our orders, I built an internal, custom merchandise management in my own PHP framework or CMS CBSM (which is also used for this blog, for example). I did this mostly out of convenience as I have and maintain this system anyhow and I needed some database tables with fitting UI for managing our merchandise, vendors, and more (even conventions we may want to run booths at).

OTOH, the public shop is (as you may notice when looking at the website) an installation of Magento 2 (i.e. the open-source version of what is nowadays called "Adobe Commerce"). We decided to run that system because we are partnering closely with MCO Shop, which is a local ham radio and electronics shop, and they already had this software running previously on the servers we share and know how to work with it, run the upgrades, and maintain it. After all, when building a new business, as in so many areas of life, it always helps if you can share some resources and knowledge with others. First, I adapted the Magento theme to make it look more "space-like", mostly importantly, having a dark instead of light background. Once that worked well enough, I still had to get those products that we actually ordered from my custom management system into this Magento shop. Initially, I did this via creating a big CSV file and importing that into the shop, but it was clear that we needed a more fine-grained solution in the long run that can add and update entries individually.

Additionally, when we run booths on our "away missions" to events/conventions (or whenever we otherwise sell anything in person), Austrian law requires us to use a cash register system that follows strict rules and passes a certification so that the government can be sure we pay taxes for everything we sell. For that we decided to use a solution integrated into our bookkeeping system, which runs online as a web service as well, a specialized Austrian solution called FreeFinance. And of course, the cash register needs a full list of products and prices as well, which we also initially solved with a CSV creation and import in anticipation of a more fine-grained solution after our first big appearance at Austria Comic-Con in early June.
Image No. 23538

As icing on the cake, we also wanted to generate nicely styled invoice documents in FreeFinance for all online shop orders that weren't paid via the cash register, and in the future, we'll want to make the online shop automatically aware of merchandise sold at events so they are removed from available stock for online purchases.

To achieve that, I looked into the APIs that both Magento and FreeFinance provide, accessing them from the custom internal system that I have full access to and that is required for providing the merchandise data anyhow. I found that the FreeFinance API is relatively simple, well-documented and does authentication via OAuth2, which I already had some knowledge of (and code to access it) from other projects, including some code already in the CBSM system for facilitating its own logins. That said, Magento is a different beast: its product catalog feature set is way more complex, and so is its API. Also, there is no well-structured collective documentation that would explain what various things mean or what is preferably done in what way (often there are multiple paths to the same result), it's a lot of turning on developer mode so that a Swagger/OpenAPI UI is available on your installation and then trying around there and searching the web for what could work how and what value could mean what. In addition, authentication is done via OAuth1, which is more complicated than its successor, and which I didn't have any pre-existing code for, though I could build on some code from their tutorial. Also, as we're running Magento ourselves on the server side, I could more easily try around things than with FreeFinance, which is a hosted service and I needed to request access credentials from their team. But FreeFinance gave us access to a testing system, whereas for Magento, for various reasons, we only have a live system and no staging/testing environment, so we can't "play around" very much when testing.

I wrote quite a bit of code for all those cases, the simplest part was and is surely updating the cash register with our products, the only slight complication there is adding categories if needed. For adding products to the shop, I needed to respect all kinds of things, like creating and managing configurable products, adding values to some attributes, uploading images, managing categories, and more. And the curious structure of the Magento API, which requires way more detailed action than the CSV import route, did at times make this even more complicated - but it works now and I can just add or change a product in the merch management and at the latest on the next day, both the shop and the cash register have updated to those changes (I can trigger the sync jobs earlier if required). For creating the invoice documents, I could base some things on a make.com "blueprint" provided by FreeFinance, but for one thing, we don't want to use a paid third-party service if we can automate this ourselves, and for the other, we have some restrictions and specialties of our own there (like only generating invoices for orders actually paid via the web shop payment integration and not in person via the cash register). I did run into some curiosities there, like the Magento order API result containing several pieces of data multiple times, or us initially using a document layout template that didn't allow for different products having different VAT rates (which we require) - but that's working now as well. The reverse part about getting cash register purchases into the online shop is still on my plate, but I now have a good plan for how to do that, and some time until our next big "away mission" where this will be important to have.

All in all, this has been a quite interesting experience, and I'm sure now that I am comfortable with working with those systems and APIs, I will do more with them in the long run - and our Trade Post 47 hopefully will still grow as well and therefore have additional requirements in the future. If you are a developer and have questions about some details, feel free to contact me - and if you are running such systems yourself and need a developer who can adapt them in a similar fashion, I'm happy to offer those services as a contractor!

Von KaiRo, um 03:51 | Tags: API, FreeFinance, Magento, merch, PHP, science fiction, Shop, Trade Post 47 | keine Kommentare | TrackBack: 0

21. Februar 2017

The PHP Authserver

As mentioned previously here on my blog, my FOSDEM 2017 talk ended up opening up the code for my own OAuth2 login server which I created following my earlier post on the login systems question.

The video from the talk is now online at the details page of the talk (including downloadable versions if you want them), my slides are available as well.

The gist of it is that I found out that using a standard authentication protocol in my website/CMS systems instead of storing passwords with the websites is a good idea, but I also didn't want to report who is logging into which website at what point to a third party that I don't completely trust privacy-wise (like Facebook or Google). My way to deal with that was to operate my own OAuth2 login server, preferably with open code that I can understand myself.

As the language I know best is PHP (and I can write pretty clean and good quality code in that language), I looked for existing solutions there but couldn't find a finished one that I could just install, adapt branding-wise and operate.
I found a good library for OAuth2 (and by extension OpenID Connect) in oauth2-server-php, but the management of actual login processes and creating the various end points that call the library still had to be added, and so I set out to do just that. For storing passwords, I investigated what solutions would be good and in the end settled for using PHP's builtin password_hash function including its auto-upgrade-on-login functionalities, right now that means using bcrypt (which is decent but not fully ideal), with PHP 7.2, it will move to Argon2 (which is probably the best available option right now). That said, I wrote some code to add an on-disk random value to the passwords so that hacking the database alone will be insufficient for an offline brute-force attack on the hashes. In general, I tried to use a lot of advice from Mozilla's secure coding guidelines for websites, and also made sure my server passes with A+ score on Mozilla Observatory as well as SSL Labs, and put the changes for that in the code as much as possible, or example server configurations in the repository otherwise, so that other installations can profit from this as well.
For sending emails and building up HTML as DOM doucuments, I'm using helper classes from my own php-utility-classes and for some of the database access, esp. schema upgrades, I ended up including doctrine DBAL. Optionally, the code is there to monitor traffic via Piwik.

The code for all this is now available at https://github.com/KaiRo-at/authserver.

It should be relatively easy to install on a Linux system with Apache and MySQL - other web servers and databases should not be hard to add but are untested so far. The main README has some rudimentary documentation, but help is needed to improve on that. Also, all testing is done by trying logins with the two OAuth2 implementations I have done in my own projects, I need help in getting a real test suite set up for the system.
Right now, all the system supports is the OAuth2 "Authorization Code" flow, it would be great to extend it to support OIDC as well, which php-server-php can handle but the support code for it needs to be written.
Branding can easily be adapted for the operator running the service via the skin support (my own branding on my installation builds on that as well), and right now US English and German are supported by the service but more can easily be added if someone contributes them.

And last but not least, it's all under the MPL2 license, which I hope enables people easily to contribute - I hope including yourself!

Von KaiRo, um 16:05 | Tags: authserver, CBSM, FOSDEM, identity, login, Mozilla, OAuth2, Persona, PHP | keine Kommentare | TrackBack: 0

23. Dezember 2016

Looking for Review on PHP Code (Login/Auth System)

Yay! My talk about "Web Logins after Persona - How I solved logins on my small websites" has been accepted for the Mozilla DevRoom at FOSDEM 2017!

That talk is a followup on my earlier post on the login systems question, which I ended up solving by writing my own OAuth2 login server based on oauth2-server-php. While that library provides the actual functionality for OAuth2, I had to build a system around it that handles the actual registration and login and the API for retrieving an email address for the logged in user.

I would like to open up the code for that server to the public at FOSDEM!

For that, I need someone (hopefully multiple people) to review the code to be sane security-wise (an in-depth audit is probably not needed yet, but review for sanity for sure), as I have it deployed myself and don't want the open code to be a risk for me, and also I want it to be fine for people to deploy and depend their own (small) websites on this system for login.

It's basically all PHP code, but it's not too much, the PHP files of the project itself are just about 900 lines long altogether, though it uses the document and email classes from my php-utility-classes as well as oauth2-server-php and a bit of doctrine DBAL, though I don't think the latter two need any review for sanity. The JS is minimal and the CSS no issue for security sanity. ;-)

I have one Mozillian who has volunteered and should look into the code soon, but I'd like to have two or three people to take a look, if possible.

If you can help, please let me know with a reply on this post (leave your email, as I'll contact you there), Telegram, Diaspora*, or email and tell me why/how you are qualified to review this code.

Thanks and Happy Holidays!

Von KaiRo, um 03:08 | Tags: BrowserID, CBSM, FOSDEM, identity, login, Mozilla, OAuth2, Persona, PHP | keine Kommentare | TrackBack: 0

Feeds: RSS/Atom