Blog du service technique de Ctoutvert

En déployant divers environnements d'exécution de nos applications : test/pré-production/validation/développement... Il est parfois nécessaire de travailler sur des données issues du monde réel : la production. Pour faire ça manuellement la procédure suivante était lancée : On demande au DBA de remonter une base de donnée Il se connecte sur le serveur Il lance une sauvegarde ou récupère une sauvegarde existante Il télécharge la sauvegarde sur son poste (des fois avec une étape de compression/décompression) Il bloque les utilisateurs sur le serveur cible Il restaure la sauvegarde sur le serveur cible Il exécute certaines requête SQL (anonymisation par exemple)  Il dit au développeur que tout est OK, qui derrière peuvent avoir à faire certaines tâches : restart application, vidage de caches... Nombreuses sont les erreurs possibles pendant ce processus : Sauvegarde du mauvais serveur / mauvaise base de donnée Restauration sur le mauvais serveur / mauvaise base de don...

Préface Il est parfois bon de se reposer des questions très simples : qu'est ce que l'authentification, et pourquoi avons nous besoin de cette couche dans une application? Si l'on en croit la définition de wikipédia : "L'authentification pour un système informatique est un processus permettant au système de s'assurer de la légitimité de la demande d'accès faite par une entité (être humain ou un autre système...) afin d'autoriser l'accès de cette entité à des ressources du système" Concrètement, livrer un projet web à un client demande de répondre (entre autres) à ces questions simples : l'application est elle publique? C'est à dire, faut-il limiter les accès, ou permettre à tout un chacun de l'utiliser? si l'application est privée, existe -il différents types d'utilisateur? Quel et le type de l'application? Site web, application web, web api, web services( ...) ? Un mélange de plusieurs types? A-t-elle besoin...

Introduction  Il y a quelques années, lorsque nous avons décidé de faire une grosse migration technologique sur l'ensemble de nos nouveaux produits, nous avons également été confrontés au besoin grandissant de structurer toute la partie développement Front-End, et y intégrer la notion de responsive, avec l'explosion de la navigation mobile et tablette. Nous utilisions déjà Bootstrap pour certaines interfaces admin en interne, et avons naturellement pensé à l'implémenter sur nos nouveaux produits, sachant qu'à ce moment là, nous étions aussi en train de repenser tout notre CMS, afin entre autre de proposer la gestion des différents affichages des éléments selon la taille des terminaux. C'était donc le moment idéal pour créer un nouvel environnement de travail en cohérence avec toutes les nouveautés de ce CMS. Pourquoi nous avons choisi d'utiliser Bootstrap ? Nous avions besoin d'un framework complet, qui utilise tout d'abord un modèle de grilles...

Comment router des URLs "hard coded" optimisées pour le référencement, dans .Net MVC 5 ?       Introduction Le routage Asp.Net MVC est extrêmement pratique pour faire face aux problématiques de référencement : l'URL "/product/barbecue-15" peut être interprétée pour afficher les informations relatives au produit d'id 15. Cependant nous ne voulions pas avoir ces identifiants dans nos urls pour qu'elles soient plus propres et donner toute la liberté aux rédacteurs pour choisir quelle URL affiche un article (et donc éviter de "/product") par exemple ("/jardin/barbecue-pas-cher." affiche les informations relatives au produit 15). Nouvel Objet – CustomRoute Pour commencer, nous avons dû créer un nouvel objet : CustomRoute. En héritant de la classe RouteBase du framework Asp.Net MVC 5 qui permet de gérer le routage des requêtes, nous allions pouvoir nous servir de cet objet pour intercepter les requêtes entrantes (router ...