lundi 27 juin 2011

Authentication System : part 2

Bonjour,


Dans la première partie de cet article, nous avons vu comment chiffrer les informations de connexion d'un utilisateur avant de les stocker dans la base de données; et nous avions une méthode login qui nous permet de comparer des signatures de mots de passe. Donc nous avions un systéme de SignUp/SignIn assez utilisable mais qui reste indépendant de notre application. C'était le but c'est vrai. 
Aujourd'hui nous allons utiliser ce système pour sécuriser notre application.


On veut que seules les pages d'accueil et de connexion soient accéssibles aux gens pas encore connectés. Et pour celà nous allons utiliser ce qu'on appelle des filtres. 
Les filtres sont des .......... voir wikipedia :)



class AppController < ApplicationController

  before_filter :logged_in, :except => [:index, :login]

  def index
     # ....
  end
  
    # ... la suite du contrôleur
end

Une fois que Rails voit le before_filter dans notre contrôleur, il effectue plusieurs choses : passer la main à la méthode appelée ( logged_in dans notre cas ) et attend que cette méthode lui donne une réponse claire : True ou False.

Une fois que la réponse est là, il lit le reste du bloc de code et l'exécute.

Nous remarquerons certainement que la méthode logged_in n'a pas encore été définie. Alors où est ce qu'on doit la définir ? dans un endroit où elle sera accessible par toutes les entités de notre application : contrôleurs et vues. Nous verons pourquoi plus tard inchaallah.


class ApplicationController < ActionController::Base


  helper_method :connected?, :logged_in


  protected 
  
  def connected?
return true if session[:utilisateur]
false
  end 
  
  def logged_in
if !connected?
redirect_to login_path 
flash[:message]= " Désolé ! Accés refusé"
    end
   
  end
end



Du nouveau ! En plus de l'utilisation de méthodes privées nous avons utilisé une nouvelle méthode : helper_method


Alors que fait cette méthode ? 


Elle permet de rendre disponible une méthode dans le scope de vues ! C'est tout ce que nous avons besoin de dire et de savoir à ce stade.


Et maintenant dans nos vues on peut s'amuser à faire : 


<% if logged_in %> 
   Bonjour
<% else %>
  <%= link_to " connexion ", login_path %>
<% end %>


Merci et bonne semaine.

vendredi 24 juin 2011

Le rendez-vous des experts: Ruby On Rails





  Une introduction à Ruby On Rails !

Le framework qui continue de révolutionner le monde du web présenté par un étudiant de SUPINFO France. Il essaie de couvrir tout ce qu'il faut savoir pour démarrer .

Authentication system for Rails applications



Bonjour,


Aujourd'hui on va parler d'un problème que nous rencontrons à chaque fois que nous devons développer une application web avec un accès contrôlé.
Je veux dire par "accès contrôlé" que nous avons besoin d'être authentifié pour pouvoir effectuer certaines opérations.


Nous avons besoin de savoir qui fait quoi ! Ce qui nous pousse à protéger certaines sections de notre application supposées être réservées aux membres.


Pour réaliser une telle tâche on a souvent recours aux "solutions" prêtes. Ces solutions sont souvent des gems/plugins.
L'avantage de ces solutions c'est qu'elles ont été testées et améliorées par des milliers de programmeurs.


Leur plus grande faiblesse est que souvent elles ne sont pas faites pour vous spécialement. Ce qui rend la personnalisation de ces solutions un peu difficile. Car pour modifier le workflow défini par défaut il faut avoir une très bonne connaissance du langage Ruby pour éviter de faire du n'importe quoi et aussi savoir comment les plugins Rails sont conçus.
Nous n'allons pas entrer dans ce sujet car trop vaste et c'est un peu tôt pour nous de l'aborder.


Alors ! Et si on veut développer notre propre solution, comment faire ?


Une solution d'authentification doit être sûre, évolutive et facile à modeler. Et pour ce faire elle doit être totalement indépendante du reste de l'application.


Je vais partager avec vous ma façon de faire. Elle est très simple. Elle consiste en l'enregistrement de la signature du mot de passe et de la clé utilisée pour chiffrer. Donc les mots de passes enregistrés dans la base de données sont indéchiffrables en cas d'attaque sur votre serveur de bases de données.


The Model


Pour utiliser ce modéle dans vos applications, vous aurez juste besoin d'avoir les attributs suivants : login, hashed_password et salt qui représentent l'identifiant de l'utilisateur, le mot de passe crypté et la clé de cryptage.





Et le processus de création d'un nouveau compte reste le même !
 Utisateur.create(:attributs)

The controller


Et dans mon contrôleur j'ai mes méthodes de login et de logout.





The view


A ce stade nous avons un systéme de login/logout et création d'un nouveau compte utilisateur avec cryptage de mots de passe. Cette solution est très simple facile à embarquer dans toutes vos applications Rails.



mercredi 8 juin 2011

Understanding Rack 2 : les middlewares

Bonjour,


Aujourd'hui, à mon réveil, j'ai senti une envie folle de coder. Donc après avoir pris ma douche, prié et pris mon petit déjeuner ( j'aurais pu vous inviter ! je sais ), je suis entré dans mon repertoire "Projets" et je suis tombé sur "Rack applications" et là je me suis rappelé que je vous dois la suite de la série "Understanding Rack" que j'ai commencée il y a quelques semaines déjà.


L'épisode 1 de cette série introduit Rack, son utilité et ses bases. Je vous conseiller de le lire avant de continuer avec cet article.


Dans cet épisode nous allons savoir ce qu'est un middleware Rack, à quoi il sert, comment en créer et surtout comment l'utiliser dans une application en production (ou en dév).


Rack middleware ?


un middleware rack est "juste" une application Rack qui a connaissance de l'existence d'autres applications Rack. J'explique ! Quand un middleware rack est invoqué, il peut passer la main à d'autres middlewares/applications pour des traitements spécifiques.


Exemple par le code :


module Rack
   class MonMiddleware
     def initialize(app)
       @app = app
     end
     def call(env)
       if @app
         status, headers, body = @app.call(env)
       else
         [ status, header, body ]
       end
     end
   end
end


Le code est assez simple et clair. Nous avons une application Rack qui "peut" passer la main à une autre application si cette dernière utilise ce middleware.


Donc, en résumé, un middleware Rack est une application utilisable par les applications Rack. Oui ! c'est tout ! ( pour le moment ).


Et pour donner un peu plus de "valeur" ou d'importance aux middlewares, nous allons parler de Rack::Restrictor.


un peu d'histoire !


Il y a quelques mois, pour le compte du SUP'Management Mauritanie,  j'ai dû écrire un petit middleware pour protéger certaines sections de leur SI.
Ils ont en place une application ( Rails ) appelée RubyCampus qui leur permet de gérer leurs étudiants, les enseignants, la paie, la gestion des examens et tout le tralala. Evidement ces modules ne sont pas tous développés par la communauté RubyCampus.


Le problème !


Après quelques mois d'utilisation ils se rendent compte qu'ils doivent restreindre l'accès à certaines parties de l'application à "leur équipe" d'informaticiens. Mais comment le faire ? Avoir deux  sous-applications : une pour les étudiants et une pour l'administration ? comment s'assurer que les étudiants ne pourront accéder qu'à "leur" application ?


la solution adoptée !


Pour régler ce problème, on a proposé que le staff devant accéder à la partie Admin soit dans un réseau et que seules les machines dans ce réseau pouvaient avoir accès à la section en question.


Mettre en place un tel réseau est chose aisée certainement ! Now la partie logicielle! 
La solution a été un middleware appelé Rack::Restrictor que vous pouvez télécharger ici. Il permet de spécifier la plage d'adresses ip acceptées et il se charge du reste.


Très simple comme solution mais ça marche.


voici le code :



Ok cool ! mais comment utilise-t-on un middleware Rack ?


Simple ! On va utiliser les fonctions du Rack::Builder !
( VOUS( certainement ) :hé ho c'est quoi Rack::Builder ? ... 
  Moi : on en reparlera plus tard )


Rack::Builder n'a que trois (3) méthodes : map, use et run.


Revenons à notre sujet. Créons une petite applicaton Rack et appelons notre middleware.



   class MonApp

     def call(env)
       status = 200
       headers= { "Content-Type" => "text/plain" }
       body   = "Bonjour tout le monde"
       return [ status, headers, body ]
     end

   end

Là nous avons une application très simple qui renvoie tout simplement une chaîne de caractéres. Mais notre application a besoin d'être sécurisée et réservée à très peu de personnes :)

pour ce faire nous allons utiliser Rack::Restrictor qui installable par " > gem install rack_restrictor ". 

   require 'rack_restrictor'


   use Rack::Restrictor, "192.168.0.1/24" 
   run MonApp.new


Ce que ça fait ! On require la gem, on appelle le middleware, on lui passe la plage que nous voulons autoriser et à la fin on lance notre application. 


PS : il faut toujours appeler votre application en dernier et prétez attention à l'ordre dans lequel vous appelez vos middlewares.


Lancer votre code et testez ! 


Je vais parler de Rack::Builder et comment embarquer des middlewares/applications Rack dans des applications web plus sérieuses écrites en utilisant Rails, Sinatra ou autre.


à plus

lundi 6 juin 2011

Rhodes ...


Coucou ça faisait un moment pour ne pas dire une éternité...
Entre plein de trucs à faire et pas de journées de 48h comprenez mon absence...
Aujourd'hui je vais vous parler aussi de mobile, pas de Haml, Hassane m'a précédé mais plutôt d'une solution à une problématique majeure.

Vous travaillez dans une entreprise ( ou pas :) ) et on vous demande de développer une application pour smartphone tournant sous IOS, Androïd, et pire on peut même vous obliger à le faire sous Windows Mobile ( sans rancune... ). Que faire ? Développer la même application sur toutes ces plateformes, c'est à dire effectuer le même travail sur autant de plateformes ? se suicider ? ( c'est une option oui ) ou encore faire du web mobile ?

Bah rassurez vous il y a une autre solution et c'est un framework basé sur ruby qui respecte de façon séduisante le principe du DRY ( Don't Repeat Yourself ), ce framework c'est Rhodes, et il permet de developper une fois son application et de Run Everywhere, il suffit juste de specifier la plateforme cible. Si si c'est bien possible!

Rhodes est un framework opensource basé sur le langage ruby qui permet de construire rapidement des applications natives en html et ruby pour la majeure partie des systémes d'exploitation des smartphones.
Rhodes integre par défaut les layout des différentes vues des smartphones et se charge d'adapter le layout au smartphone cible, la logique de rhodes est basée sur une architecture MVC tres proche de rails.

Rhodes intégre un web server, et utilise le browser control des systemes d'exploitation des smartphones afin de permettre au développeur d'ecrire du html et d'editer ses templates, toutefois l'utilisateur final n'a pas connaissance que c'est son browser qui est derriére le rendu de l'application qu'il utilise.
Aussi Rhodes n'est pas venu tout seul, il est accompagné de RhoSync qui est un sync server, un serveur séparé qui se concentre sur les web services, et permet de syncrhoniser les données avec votre application. Si vous êtes dans ce type de problématique RhoSync peut être votre solution.

Toutefois cela ne signifie pas que vous êtes dans l'obligation d'utiliser RhoSync pour synchroniser vos web services avec les données de votre application....vous pouvez en effet développer votre propre serveur et votre propre client pour la synchronisation de vos web services
Et voila comment éviter un suicide collectif .... :)

Pour en savoir plus => http://rhomobile.com
ou encore


Introduction à Haml

Introduction à Haml


Bonjour Rubyistes,

ça faisait un moment que je vous ai pas écrit et je vous demande pardon. Ce n'est pas évident de travailler toute la semaine, organiser des événements les weekend, préparer des talks et pouvoir se mettre devant mon clavier et partager avec vous :)

Et pour la reprise, nous allons faire de belles choses. Nous allons voir ensemble comment écrire des applications WEB Mobiles en utilisant  HamljQTouch et Sinatra.

Le but de cette série d'articles est de nous permettre d'écrire des applications WEB Mobiles pour rendre "nos" applications WEB plus à la portée de nos visiteurs, clients et collaborateurs.
L'avantage des applications WEB mobiles par rapport aux applications WEB "simples" est qu'elles ont un look d'applications natives. De ce fait, le visiteur se sent déjà "chez lui".

D'où me vient l'idée de cet article ?


Je travaille pour une entreprise en tant que développeur d'applications WEB (mobile et standard). Et sur la demande de nos collaborateurs, nous devrions avoir une application mobile pour chaque plateforme ( Android, Iphone, BlackBerry, Windows Mobile, Symbian et Palm Os ). Oui c'est beaucoup d'applications qui sont toutes identiques ! La solution que nous avons finalement adoptée c'est avoir une seule et unique application utilisable sur toutes ces plateformes : une application WEB mobile.


Et après une comparaison des différents outils permettant le développement d'applications WEB mobiles, mon choix ( justifié ) s'est porté sur jQTouch (jQuery mobile ). L'application a été développée en Python ( Django ).


Après avoir découvert certaines belles choses, j'ai pensé à vous :) 




Now vous savez pourquoi j'ai écrit cet article. Mais vous savez toujours pas pourquoi j'ai choisi HAML ???


HAML est un langage de templating ( pour créer ou générer des pages HTML ) tout comme le ERB, Slim et autres langages de templating. Son avantage par rapport aux autres c'est le DRY ! ( Don't Repeat Yourself ), la structation qu'il vous impose et sa Rubyesque syntaxe.


Installation de HAML

Haml est une GEM qui s'installe comme toutes les autres !

> gem install haml

haml : Basics

Haml vous permet de gérer les contenus statique et dynamique de vos pages HTML en mettant à votre disposition des "méthodes" d'accès aux éléments du document HTML.


Sur cette image on a les différentes "méthodes" d'accès et d'utilisation des tag et blocks du document HTML. 
Toutes les balises HTML sont précédées d'un %, les class CSS par un "." et les ID par un "#". C'est toutce qu'il faut savoir sur les parties statiques de votre HTML.

haml : Syntaxe

Exemple : index.haml

!!! Strict
%html
  %head
  %body
    %h1
       Bonjour tout le monde

On "compile" tout ça :

> haml index.haml 

Et le résultat est :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html>
  <head></head>
  <body>
    <h1>
      Bonjour tout le monde
    </h1>
  </body>
</html>

très simple et super cool ! Pour ceux qui aiment avoir des widgets sur leurs pages web, Haml est vraiment le truc qu'il faut.
Et maintenant ajoutons un peu de contenu dynamique !

- @text = "Ruby is awesome"
!!! Strict
%html
  %head
  %body
    %h1
       Bonjour tout le monde !
       - if 1 < 2
         =@text

Et le résultat est :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html>
  <head></head>
  <body>
    <h1>
      Bonjour tout le monde !
      Ruby is awesome
    </h1>
  </body>
</html>

Un essai avec les div !

- @maclasse = "rouge rounded"
- @text = "c'est super ça "

!!! Strict
%html
  %head
  %body
    %h1
       Bonjour tout le monde !
       %div{ :class => @maclasse }
         =@text


à vous de me dire à quoi ressemblera le résultat HTML.

Haml est très simple, intuitif et amusant. Dans le prochain article, nous allons utiliser Haml dans une application Sinatra. D'ici là amusez vous bien avec Haml et n'hésitez pas à poser vos questions et/ou faire part de vos critiques/suggestions.

PS : Haml vient avec son propre moteur de CSS appelé SASS ! Mais vous pouvez l'utiliser avec le CSS standard. On fera un tour sur le SASS. Promis :)

à Lundi prochain inchaallah.