J’ai 3 endroits à récupérer, AlloVoisins, Bilik et Google.

AlloVoisins ne permet de ne récupérer que 10 commentaires en mode non connecté. Une fois connecté en revanche, on peut récupérer les avis via une API privée avec un jeton d’authentification.

Solution: utiliser playwright pour me connecter et faire les requêtes vers l’API.

Bilik est similaire à AlloVoisins. L’API privée est cette fois du graphql pour changer un peu.

Et Google ? L’API place publique ne permet de récupérer que 5 commentaires. Mais il existe une API spéciale Business Profile API. Il faut demander l’accès et avoir (peut être) l’accès au bout de 10 jours.

J’ai demandé l’accès, sans succès pour le moment. Pas d’avis Google pour le moment.

Le code est encapsulé dans une automatisation de bridgetown, le générateur du site.

Je n’y avais pas prêté particulièrement attention. Ma solution avait été de désactiver la redirection http -> https coté Phoenix, ceci étant déjà réalisé coté Traefik, mon reverse proxy.

Les années passent et les problèmes cachés sous le tapis finissent par revenir. En voulant déployer une instance de Nerves Hub, je suis tombé a nouveau sur le problème. J’ai décidé cette fois d’enquêter.

Je me suis douté tout de suite que le problème soit dû au fait de forcer https sur l’instance. Lorsque c’est une requête https classique ca passe, mais websocket non.

1. Désactiver la redirection http -> https coté Traefik: Problème toujours présent.
2. Chercher sur les forums des problèmes similaires: j’en trouve 2, mais sans solution satisfaisante.
   • https://elixirforum.com/t/plug-ssl-redirects-socket-connection-problem-301/25347
   • https://elixirforum.com/t/force-ssl-fails-to-upgrade-websocket-but-manual-plug-ssl-plug-works-fine/73990
3. Lire la doc et le code du Plug.RewriteOn qui s’occupe de la logique. Relire la doc de Traefik pour vérifier qu’il envoie bien l’entête http X-Forwarded-Proto. La réponse est oui.
4. Inspecter les entêtes https fournis par le serveur. Je suis tombé sur le projet docker-http-https-echo qui est juste parfait pour cela. Je le lance sur mon serveur:

   docker \
     run  \
     --rm \
     --network traefik \
     --label traefik.enable=true \
     --label 'traefik.http.routers.test.rule=Host(`test.2metz.fr`)' \
     mendhak/http-https-echo:39
   

   En effectuant ma requête websocket, je me rends compte que la valeur de X-Forwarded-Proto est wss.

   Je tombe sur l’issue de Traefik qui parle justement de cette valeur pas très standard https://github.com/traefik/traefik/issues/6388

A ce moment la, je pense avoir trouvé la source du problème. La valeur wss n’est pas attendu par Plug.RewriteOn, et redirige donc vers la version https pensant que c’est une requêtes non chiffré. Reste à trouver une solution.

Je tente alors de forcer la valeur de l’entête X-Forwarded-Proto a https par Traefik:

  docker \
    run \
    --rm \
    --network traefik \
    --label traefik.http.routers.test.middlewares=test@docker \
    --label traefik.http.middlewares.test.headers.customrequestheaders.X-Forwarded-Proto=https \
    --label traefik.enable=true \
    --label traefik.http.routers.test.rule='Host(`test.2metz.fr`)' \
    mendhak/http-https-echo:39

Et cela fonctionne ! Mon instance Nerves Hub fonctionnelle, je peux désormais proposer un patch https://github.com/elixir-plug/plug/pull/1302/.

Désormais chaque contact d’un client a droit a sa vcard. En conséquence si un client n’a pas de contact, aucune entrée n’est affichée.

Les contacts des clients professionnels sont traités un peu différemment. Une vcard de type group est créé et les contacts du client y sont associés. Cela permet de retrouver rapidement les contacts d’une entreprise particulière.

Un contact spécial, avec le nom de la société, a été rajouté pour l’envoi des factures ou justificatifs dans Tiime. Fini le copier-coller depuis l’interface web, vous pouvez faire suivre les factures en 2 clics.

En plus de cela quelques corrections ont été faites:

• les clients archivés ne sont plus affichés
• le champ etag a été correctement rempli pour éviter des problèmes de cache pour certains clients

Le code est ici: https://github.com/francois2metz/tiime-carddav

Une fois le devis réalisé, ma base de données de référence de mes clients est Tiime. J’ai toutes les informations sur ceux-ci dessus, le nom, adresse, email et téléphone. Ces informations sont nécessaires pour avoir un devis correct, mais aussi pour que la signature électronique que je propose fonctionne.

Bref, tout cela pour dire que en cherchant une solution a ce problème, la solution technique la plus simple et la plus universelle était d’exposer un serveur carddav de mes clients à partir de Tiime. De cette façon je peux les récupérer sur mon téléphone (via DAVx5) ou sur mon ordinateur (via vdirsyncer). J’ai réutilisé le client go que j’avais développé pour le plugin steampipe, et fait la logique nécessaire pour avoir un serveur carddav fonctionnel.

Comme j’aime bien m’amuser, j’ai géré les multiples sociétés dans Tiime (sous forme de carnet d’adresses séparé) et il peut gérer n’importe quel compte Tiime, pour peu que les données d’authentification soient correctes.

De cette façon, je peux envoyer un email a un client sur mon ordinateur, savoir qu’il m’appelle ou encore lancer la navigation sur mon téléphone portable.

Le code est ici: https://github.com/francois2metz/tiime-carddav

J’ai été confronté à la nécessité de faire parvenir les devis a mes clients, et faire signer ceux-ci sans frictions.

J’avais quelques contraintes:

• pour mon suivi de facturation, je voulais continuer a utilisé Tiime, le logiciel de comptabilité fourni par mon cabinet comptable
• étant en vélo, je ne voulais pas d’imprimante pour faire les signer directement sur place
• pour limiter la friction, je ne voulais pas forcer mes clients à avoir une imprimante ou utiliser un logiciel tiers d’édition PDF
• pour ne pas avoir de problèmes légaux, je voulais être irréprochable sur la signature du devis

Tiime étant un logiciel mature, une application mobile Tiime est disponible qui me permet de faire mes devis facilement et de les envoyer par email. Mais la signature restait le principal problème.

Comme partenaire de signature électronique, j’ai sélectionné Docage. Étonnement, c’est le service qui me permettait d’utiliser l’API de signature sans avoir a payé un prix conséquent par mois. Docage a un cout mensuel par utilisateur et par devis signé modique.

Mais préparer la transaction (dans le jargon de Docage) est un peu chronophage et redondant par rapport au devis, et Tiime ne proposant pas ce service nativement, j’ai réalisé l’intégration qu’il me fallait.

Et c’est ainsi que Siign est né. Ce service s’interface avec Tiime et Docage et permet de:

• lister les devis du compte Tiime
• créer la transaction Docage en 1 clic (informations du client, devis, etc …) en reprenant les informations de Tiime
• partager le lien de la transaction Docage au client
• faire signer le client dans une interface en marque blanche
• mettre à jour le devis dans Tiime une fois que celui-ci est signé (ou refusé, expiré, …)
• recevoir une notification SMS avec le nouveau statut du devis

Il est bien sur toujours possible pour le client de procéder d’une manière plus ancestrale, en téléchargeant le devis et en le signant via impression ou en utilisant un logiciel d’édition PDF pour opposer sa signature.

Siign a été utilisé par mes premiers clients assez naturellement, je suis pour l’instant assez content du résultat.

Si cela vous intéresse je serais ravi de déployer un tel service pour vous. L’instance est déployée sur signature.2metz.fr.

Bien sur, le code est libre (licence AGPL v3) et disponible sur GitHub: github.com/francois2metz/siign.

One of the challenge was to find a replacement of vue-mapbox library I was using. I quickly found vue-maplibre-gl that is mostly a drop-in replacement. Some features were missing so I forked the project to add them. While at it, I added documentation, updated dependencies, removed some features, etc …

The fork is published on npm at @indoorequal/vue-maplibre-gl and the documentation is available.

Monitoring our software dependencies has never been a subject followed by Pix. The updates were therefore made by a few people.

In the past, a small team had been created to update Ember on our client applications. It works well in a swing, but does not solve the follow-up problem.

That is why Renovate was set up. Renovate is present on all our repositories and constantly pushes us with updates to our dependencies. With the Dependency dashboard (see 1024pix/pix), we can have the different updates on hold. This gives us an idea of the delay, but it is still very rude.

That is why, at the Tech Days 2023 (technical work done during the summer), a team was tasked with putting effort back on addiction updates. The job has been to switch to node 18 on our main app and configure Renovate so that everything runs.

The need to quantify in a common way the delay in updating dependencies on the various projects has led us to interest in an interesting metric, libyear.

Libyear to the rescue

In short, libyear makes it possible to quantify the age of all dependencies.

By calculating this metric on our different projects, we have a comparable measure to see and decide on the updating actions. That’s why we’ve developed dependency-drift-tracker that allows us to know the current drift of our dependencies, see evolution and compare that delay with others.

In addition to the delay in our dependencies, we also show the measurement in years since the last release, called Pulse. This makes it possible to identify dependencies that have become obsolete or devalued. This requires a slightly more manual analysis.

What does it look like?

On the left, in the blink of an eye, we see the deposits followed with the information of the delay. Then in the main panel, 2 metrics are displayed, the delay and the pulse.

The following 2 graphs make it possible to monitor the evolution of these figures over time.

Finally, the final table displays the result of the last launch of libyear with the information of individual dependencies.

The data are refreshed every day. A delay that is regular enough to enhance the work done the day before, and to plan the rest.

Conclusion

Making our delay visible has enabled us to improve on the tracking of versions. Seeing the decrease in the curve after an update is always a pleasure. Even if, in a continuous way and does it seem inexorable, the curve goes back as a result of the updates of the dozens of dependencies used by our applications.

Curious, here’s the follow-up of the Pix applications.

Try it

We made the generic tracking code usable by any javascript project. You can easily manage tracking files manually via dependency-drift-tracker, or even more simply with the GitHub dependency-drift-tracker-action action.

And read the documentation.

Le suivi de nos dépendances logiciels n’a jamais été un sujet suivi chez Pix. Les mises à jour se sont fait donc au bon vouloir de quelques personnes.

Dans le passé, une petite équipe avait été créée pour mettre à jour Ember sur nos applications clientes. Cela fonctionne bien par à-coups, mais ne règle pas le problème de suivi.

C’est pourquoi Renovate a été mis en place. Renovate est présent sur tous nos dépôts et nous pousse en permanence des mises à jour de nos dépendances. Avec le “Dependency dashboard” (voir celui de 1024pix/pix), nous pouvons avoir les différentes mises à jour en attente. Cela nous donne une idée du retard mais cela reste très grossier.

C’est pourquoi lors des Tech Days 2023 (du travail technique réalisé pendant l’été), une équipe s’est chargée de remettre de l’effort sur les mises à jour de dépendances. Le travail a été de passer à node 18 sur notre application principale et de configurer Renovate pour que tout roule.

Le besoin de quantifier d’une manière commune le retard de mise à jour des dépendances sur les différents projets nous a amené à nous intéresser à une métrique intéressante, libyear.

Libyear à la rescousse

En bref libyear permet de quantifier l’âge de l’ensemble des dépendances.

En calculant cette métrique sur nos différents projets, nous avons une mesure comparable pour constater et décider des actions de mise à jour. C’est pourquoi nous avons développé dependency-drift-tracker qui nous permet de connaitre la dérive actuelle de nos dépendances, de voir l’évolution et de comparer ce retard avec les autres.

En plus du retard de nos dépendances, nous affichons également la mesure en années depuis la dernière release, appelée Pulse. Cela permet de repérer des dépendances qui sont devenues obsolètes ou dépréciées. Cela nécessite une analyse un peu plus poussée manuelle.

A quoi cela ressemble ?

À gauche, en un clin d’œil, on voit les dépôts suivis avec l’information du retard. Ensuite dans le panneau principal, 2 métriques sont affichées, le retard et et le pulse.

Les 2 graphs suivants permettent de suivre l’évolution de ces chiffres à travers le temps.

Enfin le tableau final affiche le résultat du dernier lancement de libyear avec les informations de dépendances individuelles.

Les données sont rafraîchies tous les jours. Un retour suffisamment régulier pour valoriser le travail accompli la veille, et planifier la suite.

Conclusion

Rendre visible notre retard nous a permis de nous améliorer sur le suivi des versions. Voir la baisse de la courbe après une mise à jour est toujours un plaisir. Même si, d’une manière continue et semble t’il inexorable, la courbe remonte suite aux mises à jour des dizaines de dépendances utilisées par nos applications.

Curieux·ses, voici le suivi des applications Pix.

Essayez-le

Nous avons rendu le code de suivi générique pour être utilisable par n’importe quel projet javascript. Vous pouvez facilement gérer les fichiers de suivi manuellement via dependency-drift-tracker, ou encore plus simplement avec l’action GitHub dependency-drift-tracker-action.

Et lisez la documentation.

Thanks to a new JOSM plugin, it is now possible to preview your changes from JOSM with one click, similar to the OsmInEdit integration.

It adds a menu entry in the “More tools” entry and on click it open the the current layer on indoor= as a preview.

indoorequal.com is a small app with only a handful of authenticated endpoints and an API to check the keys. Besides register and login workflow, the reset password and confirmation email extensions are enabled. There is also a role system that is used only for administration purposes.

My goal was to switch the authentication system without breaking anything from a user point of view while keeping the same features.

Login with previous accounts

After generating the initial boilerplate I saw that phx.gen.auth use different column names than pow

• the column email_confirmed_at is named confirmed_at
• the column password_hash is now hashed_password

So I renamed I updated the code to use email_confirmed_at instead of confirmed_at (enabling me to go back to the master branch without resetting my database).

For the password, my initial thought was to use the same hashing library than Pow, namely pbkdf2. So I renamed hashed_password to password_hash in the code. But soon after trying to login with an account created with pow, I got the following error: (FunctionClauseError) no function clause matching in Pbkdf2.Base64.dec64/1.

The library pbkdf2_elixir used by phx.gen.auth and the pbkdf2 implementation by Pow have some incompatibilies. pbkdf2_elixir encode the different parts of the string using a restricted version of base64 (no padding, no point). My solution was to migrate the previous password to the new hashing algorithm on first login.

The initial migration was also updated to not create the users table (commented out for future references).

defmodule Indoorequalcom.Repo.Migrations.CreateUsersAuthTables do
  use Ecto.Migration

  def change do
    execute "CREATE EXTENSION IF NOT EXISTS citext", ""

    #create table(:users) do
    #  add :email, :citext, null: false
    #  add :hashed_password, :string, null: false
    #  add :confirmed_at, :naive_datetime
    #  timestamps()
    #end

    #create unique_index(:users, [:email])

    create table(:users_tokens) do
      add :user_id, references(:users, on_delete: :delete_all), null: false
      add :token, :binary, null: false
      add :context, :string, null: false
      add :sent_to, :string
      timestamps(updated_at: false)
    end

    create index(:users_tokens, [:user_id])
    create unique_index(:users_tokens, [:context, :token])
  end
end

I created a new migration for the email column that has to be changed to citext, and the new column to the store the password:

defmodule Indoorequalcom.Repo.Migrations.UpdateUsersEmail do
  use Ecto.Migration

  def change do
    alter table(:users) do
      modify :email, :citext, from: :string
      add :hashed_password, :string
    end
  end
end

It’s now time to try the login with a previous user account. I created a test case like that in accounts_test.ex:

defmodule Indoorequalcom.AccountsTest do
  ...
  describe "get_user_by_email_and_password/2" do
    ...
    test "returns the user if the password has been generated by pow" do
      %{id: id} = user = user_fixture()
      user
      |> Ecto.Changeset.change(%{password_hash: Pow.Ecto.Schema.Password.pbkdf2_hash(valid_user_password())})
      |> Indoorequalcom.Repo.update()

      assert %User{id: ^id} =
        Accounts.get_user_by_email_and_password(user.email, valid_user_password())
    end
    ...
  end
  ...
end

The implementation in accounts.ex.

defmodule Indoorequalcom.Accounts do
  ...
  def get_user_by_email_and_password(email, password)
      when is_binary(email) and is_binary(password) do
    user = Repo.get_by(User, email: email)
    case User.has_password_from_pow?(user) do
      true ->
        if User.valid_password_from_pow?(user, password) do
          user
          |> User.password_from_pow_changeset(%{password: password})
          |> Repo.update!()
        end
      false ->
        if User.valid_password?(user, password), do: user
    end
  end
end

And the functions in user.ex:

defmodule Indoorequalcom.Accounts.User do
  ...
  @doc """
  A user changeset for changing the password from pow one to phx.gen.auth
  ## Options

    * `:hash_password` - Hashes the password so it can be stored securely
      in the database and ensures the password field is cleared to prevent
      leaks in the logs. If password hashing is not needed and clearing the
      password field is not desired (like when using this changeset for
      validations on a LiveView form), this option can be set to `false`.
      Defaults to `true`.
  """
  def password_from_pow_changeset(user, attrs, opts \\ []) do
    user
    |> cast(attrs, [:password])
    |> put_change(:password_hash, nil)
    |> maybe_hash_password(opts)
  end

  @doc """
  Check is there is a password previously set from pow
  """
  def has_password_from_pow?(%{password_hash: password_hash})
    when is_binary(password_hash) do
    true
  end

  def has_password_from_pow?(_) do
    false
  end

  @doc """
  Verify the password from pow
  """
  def valid_password_from_pow?(%Indoorequalcom.Accounts.User{password_hash: password_hash}, password) do
    Pow.Ecto.Schema.Password.pbkdf2_verify(password, password_hash)
  end
end

The solution was to look for the content of the password_hash column. If the column is non empty, then it means that the account was created via pow. The password is checked against Pow pbkdf2 implementation and if it matches, the password is hased with argon2 and stored in the column hashed_password and the previous column is resetted.

Check user email before login

To reproduce the Pow’ user email confirmation, there is 2 places to update:

• on registration to not login the user
• on login to check that the user is confirmed

After registration, update the file user_registration_controller.ex.

defmodule IndoorequalcomWeb.UserRegistrationController do
  ...
  def create(conn, %{"user" => user_params}) do
    case Accounts.register_user(user_params) do
      {:ok, user} ->
        {:ok, _} =
          Accounts.deliver_user_confirmation_instructions(
            user,
            &url(~p"/users/confirm/#{&1}")
          )

        conn
        |> put_flash(:info, "You'll need to confirm your e-mail before you can sign in. An e-mail confirmation link has been sent to you.")
        |> redirect(to: ~p"/")

      {:error, %Ecto.Changeset{} = changeset} ->
        render(conn, :new, changeset: changeset)
    end
  end
end

On login, the code involved an update to accounts.ex

defmodule Indoorequalcom.Accounts do
  ...
  def get_user_by_email_and_password(email, password)
      when is_binary(email) and is_binary(password) do
    case get_valid_user_password(email, password) do
      nil -> {:error, :invalid}
      user ->
        case user.email_confirmed_at do
          nil -> {:error, :email_not_confirmed, user}
         _ -> user
        end
    end
  end

  defp get_valid_user_password(email, password) do
    user = Repo.get_by(User, email: email)
    case User.has_password_from_pow?(user) do
      true ->
        if User.valid_password_from_pow?(user, password) do
          user
          |> User.password_from_pow_changeset(%{password: password})
          |> Repo.update!()
        end
      false ->
        if User.valid_password?(user, password), do: user
    end
  end
end

And in the session controller to catch the error to display a specific message and (re)sending the email.

defmodule IndoorequalcomWeb.UserSessionController do
  ...
  def create(conn, %{"user" => user_params}) do
    %{"email" => email, "password" => password} = user_params

    case Accounts.get_user_by_email_and_password(email, password) do
      {:error, :invalid} ->
        # In order to prevent user enumeration attacks, don't disclose whether the email is registered.
        render(conn, :new, error_message: "Invalid email or password")
      {:error, :email_not_confirmed, user} ->
        Accounts.deliver_user_confirmation_instructions(
          user,
          &url(~p"/users/confirm/#{&1}")
        )
        render(conn, :new, error_message: "You'll need to confirm your e-mail before you can sign in. An e-mail confirmation link has been sent to you")
      user ->
        conn
        |> UserAuth.log_in_user(user, user_params)
    end
  end

Conclusion

Once I got the way to migrate from Pow with password, the process to migrate went smoothly. I only described the main points to look at, but there a lot of things to do before going live:

• tests to update the new log_in workflow
• style all forms
• plug and customize emails
• …