powerful Bundled Products
to directly increase your revenue by selling
more products than with cross-selling!
It looks amazing, check the demo
conditional and reusable custom options
with Single Sign-On
increase your security by connecting
your webshop to an Identity Provider
From the Blog
Larger companies usually have multiple people involved in a Magento 2 project, including several developers, project managers, internal customers, end customers and other steakholders.
All these people benefit from a properly maintained and properly running Magento 2 webshop.
To properly maintain the quality of a webshop there's multiple factors in place besides the development process itself, including but not limited to the proper use of version control, project managmeent, release management, unit testing, functional testing and more.
To facilitate this, companies usually use multiple environments to run the project on, which allows developers to efficiently develop code without others constantly being stopped in their tracks while code is still buggy or in active development.
This is where DTAP usually comes into play. This short blog is ment as a technical guide into how to quickly and effectively manage a DTAP environment for your Magento 2 projects.
What is DTAP?
DTAP is an abbreviation for "Development, Testing, Acceptation and Production" and resembles the 4 environments which the project takes to ensure new versions of are properly developed and tested without the end users and customers having to worry about unfinished results.
DTAP Best Practises
Combining Testing and Acceptation to remove overhead
In small to medium sized team, the Testing and Acceptation server is most likely combined into one environment. This is because there's usually not a party involved who would require a separate Acceptation environment. Therefor a D(TA)P environment is very often just 3 environments.
A situation where 4 environments is used, is when a project team tests on the Testing environment, while other steakholders test on Acceptation prior for a new version to make it to production.
Automating deployment to remove human error
Over the last view weeks we have gotten a lot of questions about how to upgrade the old Wizkunde WebSSO extension now that Wizkunde is no longer existing. We wanted to reach out to you and give you an update and provide you the best way to receive the new GoGento version for your Magento platform.
Backwards compatibility with the Wizkunde WebSSO extension
The GoGento extension has been rewritten from the ground up and therefor its not a matter of replacing your old extension with the new one. The old extension was very dynamic and allowed customers to create a very generic SSO connection suitable for most identity providers with either SAML2 or OAuth2 as its protocol.
This solution caused a lot of support cases and often required a lot of help from us to get the SSO connection going, because it was quite a technical process.
We wanted to strongly simplify the way the integration was setup and still make it possible to customize the way the integration works without a lot of work. In this way we can both reduce the incoming support as simplify the codebase so that it does exactly what you need it to do without having to be a developer.
Choosing solution over the technical details
In the past customers had to know about the protocols used and such. However in the new situation, we got it all sorted for you. Our extension uses the right protocol and if possible, we choose the protocol thats available to your Identity Provider with the most features aswell as those which does not cause you to pay extra money on the identity provider side to get it working.
Therefor, we no longer offer our SSO extension in the way of a "SAML2" integration or a "OAuth2" integration, but provide a working, optimized end-solution.
Isnt this restricting the extension too much?
Definitely not because the new extension is just as expandable as the old extension, but in
Semantic Versioning for Extensions
So you are either looking for the best way to provide versioning for your extensions or maybe you do have a working versioning system and are looking for ways to improve it. This blog gives you our perspective on future-proof extension versioning. It does not matter if you develop extensions for Magento 2, WordPress, Drupal or any other third-party platform. This Semantic Versioning Model allows you to build a bulletproof solution which will work properly for years. It is designed to be able to be linked to the versioning of the platform, allowing customers to stay up to date without having to worry about installing a version which breaks due to platform incompatibility
Why a blog about hacking with docker
Many companies allow their customers to see / manage the docker containers by allowing them to be in the docker group. After all, tts very easy to say "Just hop on to the php container to do your work".
Due to the way docker works, the docker engine needs escalated privileges to manage its containers and that means, anyone in the docker group, effectively has root access to the server.
Your customer might not know this, but malicious users, who can beg, steal and borrow your customers ssh credentials, most definitely will.
In our example, we've given our user sudo rights, but effectively you can achieve everything, including spionage.
As an actual recent case, i had to modify SSH information to allow PasswordAuthentication and to force the server to reboot.
To force the host to reboot from a container, you can add: -v /dev:/dev:rw to the docker run command.
From there on, if you type reboot inside the container, it will use the server socket instead of the container socket and reboot itself.
Lets get our hands dirty with an useful example
1. It begins with a basic setup
In this example, i created a fresh Ubuntu 20.04 Server on Digital Ocean and proceded with the installation of Docker. I added a user called "hacker" and added it to the docker group.
From there on, i could SSH to the docker server as expected.