Using OpenID Connect for Single Sign-On with Drupal

At Commerce Guys we provide a varied range of services, including our cloud PaaS Platform.sh, this Drupal Commerce community website, support, and the Commerce Marketplace.

Our users may need to log in to any of these services, and sometimes several at the same time. So we needed to have a shared authentication system, a way of synchronizing user accounts, and single sign-on (SSO) functionality.

After a lot of research on the existing methods, such as CAS, we found that there was no generic open-source solution which would cover all of our current needs and would also allow us to grow and scale in the future when adding new features or applications.

We decided to implement the OAuth 2.0 and OpenID Connect protocols, which were designed to be flexible, yet simple and standardized - exactly what we wanted.

Patrick Dawkins
Posted: Feb 17, 2015

Shipping the Future

Shipping Requirements Have Changed

Heretofore, shipping has focused on exposing a simple yet effective API for connecting rating and shipping companies to the checkout process. Many stores eschew real-time rating and instead opt to offer flat-rate shipping or free shipping on orders. This entirely removes the need for rating. For those who do use real-time rating, the existing process offers a simple set of tools that are only adequate for simple shipping needs.

Tags: 
Nicholas Vahalik
Posted: Jan 29, 2015

Major improvements in addressfield 7.x-1.0-rc1

Many people know that addressfield hasn’t been the easiest module to maintain. There are over 200 countries in the world, each with its own addressing requirements. Addressfield attempted to provide a sane default for all of them, along with a plugin architecture for handling per-country customizations. But with so many countries, the list of needed improvements became never-ending, and the customizations themselves started gathering in only one plugin (address.inc), which quickly became impossible to maintain.

A radical change was needed, so after a lot of research we introduced a new plan for Drupal 8, along with a brand new PHP library we can depend on from addressfield 8.x-2.x. The new plan resolves around two powerful ideas:

  • The introduction of address formats, which hold information on how a country’s address and its form need to be rendered and validated.
  • The use of Google’s addressing dataset, freely available and built for Chrome and Android, with address formats for 200 countries.

The introduced solutions were obviously superior to anything we had before that, but Drupal 8 is still far from production, and we needed improvements on our Drupal 7 sites today, so we decided to try and backport as many concepts as we could into the 7.x-1.x codebase. The result of that is addressfield 7.x-1.0-rc1:

Read more...

Tags: 
Bojan Zivanovic
Posted: Dec 15, 2014

How to switch your payment settings based on environment variables using Platform.sh

When working on a Commerce project which uses a payment gateway, you need to always make sure that your Staging and Development environments are properly targeting the sandbox or test mode of your payment gateway, and that your Production site is targeting the live account.

This is actually true for any third-party service integration which provides a sandbox where you can test. The objective is to make sure you never send test data on a live account, no matter the service you're testing on.

For this tutorial, I will focus on payment method settings, but the principle remains the same for any other third-party integration.

I will start from an empty Drupal site hosted on Platform.sh and go through the following steps:

  • Enable and configure Paypal WPS payment method
  • Export its configuration to a settings.local.php file
  • Override its Sandbox configuration on the Staging environment
  • Write custom code to read the configuration from the settings.local.php

As you see, the goal (as always with Drupal) is to read the configuration from your code so that you can easily switch from a sandbox mode to a live mode.

Augustin Delaporte
Posted: Dec 4, 2014

Commerce 1.x enhances cart calculation and order management

Have you heard about all the great new features being developed for Commerce 2.x?

Order configuration screenshot

Well, there's lots to talk about for Commerce 1.x as well. Over the last few months, we've released a number of features that are definitely useful for over 50,000!! existing Drupal Commerce stores and good to know about for future shop implementations:

Read More

Tags: 
Josh Miller
Posted: Dec 3, 2014

Commerce 2.x Stories: Taxes

"Why doesn’t Commerce/Magento/$otherSolution handle my taxes properly? That’s the most basic feature!” - many people, often.

When it comes to eCommerce, nobody likes taxes. We expect taxes to “just work”, so we can finish our projects and get on with our lives. At the same time, no other topic is as complex.

Selling online puts us at the crossroads of different (and sometimes conflicting) laws with many rules and even more exceptions. All eCommerce systems provide the basic tools (“Define your tax rates and specify when to apply them”) and make the site developer responsible for tax compliance. The developer usually passes that responsibility to the client, sometimes implicitly. The client consults an accountant, sometimes. But the buck has to stop somewhere, and it often comes back to the developer, 5 days after launch.

As taxes become more and more complex, there is a need for smarter tax handling, where the application does more and the site administrator less. In the Commerce 1.x lifecycle we’ve built the commerce_vat module to handle the more and more complex VAT taxes. For 2.x, we’re bringing this approach back into core, and releasing several libraries to share the solution with the wider PHP community.

Read more...

Bojan Zivanovic
Posted: Nov 20, 2014

Commerce 2.x Stories - Addressing

Welcome to the second article in the “Commerce 2.x Stories” series. This time we’re going to talk about addressing, and our efforts to improve the already good Commerce 1.x addressing implementation (addressfield).

By addressing we mean storing, manipulating and formatting postal addresses, meant to identify a precise recipient location for shipping or billing purposes.

Read on to see what we're doing to improve it...

Bojan Zivanovic
Posted: Sep 24, 2014

Updating Drupal Commerce created usernames

Thanks to the work of the Drupal security team, we released Drupal Commerce 7.x-1.10 on September 10 to address an information disclosure vulnerability. Last week we released a companion module to that update, Commerce Username Update, to help administrators manage the username update the release requires. The new version also includes a handful of minor bug fixes and a new feature to better support free order notifications on the checkout form.

Read more to learn more about the patched vulnerability and new feature.

Ryan Szrama
Posted: Sep 21, 2014

Commerce 2.x Stories - Internationalization

Welcome to the first article in the “Commerce 2.x Stories” series. As Commerce 2.x development heats up, we’ll be covering interesting developments, ideas, and contributors.

Our first topic of interest is internationalization and localization. This involves tasks from translating UIs and content to representing numbers, currencies, and dates in a locale specific manner. It’s also a current pain point with Drupal 7 / Commerce 1.x - especially as it relates to currency management.

Read on to see what we're doing to improve it...

Bojan Zivanovic
Posted: Aug 29, 2014

Converting Your Existing Platform.sh Development Environment to a Makefile

Platform.sh build window: Building as a vanilla project, you are missing out!

One of the most exciting features of Platform.sh is it’s ability to use Drush makefiles to rapidly prototype sites. By default, new projects can start with a makefile that will automatically add Commerce Kickstart or vanilla Drupal. Then, using the makefile, you can add new modules, themes, and libraries, by simply adding a few lines to the makefile and commiting. When you push the changes to your platform, the entire site will be rebuilt. Plus, whenever you’re in “makefile mode” any extra files that are in the root of the respository get pushed into sites/all/default. So if you have any custom modules, you can just stick them in modules/ and they’ll end up in sites/all/default/modules. This can make your code bases not only small, but far more manageable. You can convert a site that isn’t a makefile into a makefile. And in this post, that’s exactly what we’re going to do.

Nicholas Vahalik
Posted: Jul 21, 2014

Pages

Subscribe to RSS - Planet