LibLogicalAccess : bibliothèque C++ pour la RFID

Posté par Maxime C. le 16 juillet 2013 à 13:52. Édité par Florent Zara et Nils Ratusznik. Modéré par Nils Ratusznik. Licence CC By‑SA.

Étiquettes :

juil.

2013

LibLogicalAccess, une nouvelle bibliothèque logicielle destinée à la lecture / écriture sur les puces RFID, est disponible depuis quelques semaines aux intéressés de l’identification par radio fréquence. Sous licence LGPL, elle se positionne comme une alternative C++ libre pour Linux et Windows à l'utilisation de puces RFID avec des lecteurs dépourvus de contrôleur NFC (n'entrant donc pas sous le giron de la libnfc), majorité des lecteurs déployés dans le monde aujourd'hui.

La bibliothèque supporte une variété de lecteurs de bureau compatibles PC/SC (Gemalto, Omnikey, SpringCard, Cherry, …) et de lecteurs de contrôle d’accès (héritage de la société ISLOG où est né le projet). En parallèle, une grande partie des technologies de puces RFID utilisées pour l’identification des personnes est pour l’heure implémentée au sein de la bibliothèque (Mifare Classic, Mifare DESFire, Mifare Ultralight C, Tag-It, iCode 2, …).

Fonctionnant sous Linux et Windows, 32 et 64 bits, elle peut facilement être installée sous Debian au travers de paquets deb. Sous Windows, un wrapper COM permet une utilisation simple et purement orientée objet de la bibliothèque dans d’autres langages, tels que C# .NET et Delphi.

Aller plus loin

Page officielle du projet (470 clics)
Exemples de code (462 clics)
Téléchargements (172 clics)
Annonce du passage sous LGPL de LibLogicalAccess (54 clics)

# juste comme ça

Posté par maboiteaspam le 16 juillet 2013 à 14:07. Évalué à -3.

Faire du libre pour promouvoir < l’identification des personnes > par RFID, vous en pensez quoi ?

Si le libre à l'origine est née d'une bande paranoïaque, à tord ou à raison là n'est pas la question, n'est ce pas un extraordinaire revirement que de voir le libre participer à l'effort d'aliénation des hommes par la machine en supportant de tels projets ?

Ou c'est juste moi ?…
- [^] # Re: juste comme ça
  
  Posté par christophe vincent le 16 juillet 2013 à 14:23. Évalué à 5.
  
  Présenté comme ça, moi aussi, ça m'en a agité une (mais l'autre est calme).
  Par contre, je viens juste de galérer pour migrer un système de gestion d'accès par puces RFID sous Fedora, et pour tout dire, je comptais abandonner tant l'éventail de softs libres est maigre. Maintenant, je vais retenter l'expérience avec ces nouvelle lib qui j'espère m'aideront.
  - [^] # Re: juste comme ça
    
    Posté par maboiteaspam le 16 juillet 2013 à 14:32. Évalué à -5.
    
    banal exemple des petits renoncements quotidien qui nous mène probablement à ma petite réflexion ?
    Et puis comme on subit plus notre environnement qu'on ne le façonne, j'ai envie de participer à l'effort moi aussi, et de dire :
    c'est la vie, c'est comme ça LaTeX, c'est moche … :-/
    - [^] # Re: juste comme ça
      
      Posté par paralax le 16 juillet 2013 à 16:31. Évalué à 8.
      
      Maîtriser une technologie présente toujours des avantages, même si la technologie en question est d'un usage douteux. Ne serait-ce que pour pouvoir la saboter.
      - [^] # Re: juste comme ça
        
        Posté par deasy le 16 juillet 2013 à 21:55. Évalué à 2. Dernière modification le 16 juillet 2013 à 21:55.
        
        Je plussoie car c'est avec des mots sans doute différents que j'allais dire la même chose .
        Il est toujours bon de maitriser une technologie.
- [^] # Re: juste comme ça
  
  Posté par devnewton 🍺 (site web personnel) le 16 juillet 2013 à 14:34. Évalué à 10.
  
  Les puces RFID ont des usages légitimes, par exemple le suivi de matériel (bennes, outils, …). De la même façon qu'une caméra peut aussi bien servir à faire un film qu'à la vidéosurveillance ou un couteau à couper un saucisson ou trucider son voisin.
  
  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
  - [^] # Re: juste comme ça
    
    Posté par CrEv (site web personnel) le 16 juillet 2013 à 17:23. Évalué à 7.
    
    C'est triste ton avis sur le saucisson…
# Sa compil pa

Posté par Anonyme le 16 juillet 2013 à 19:22. Évalué à 1.
Bon, un peu de sérieux.

commit 0dc51f742574e7bfbdef3111c90068c05148120c
Author: Adrien JUND adrien.jund@epitech.eu
Date: Thu Jul 4 11:15:23 2013 +0200

Fedora 19, GCC 4.8 :
```
    In file included from liblogicalaccess/plugins/cryptolib/src/evp_pkey.cpp:8:0:
liblogicalaccess/plugins/cryptolib/include/logicalaccess/crypto/rsa_key.hpp: In member function ‘bool logicalaccess::openssl::RSAKey::boolean_test() const’:
liblogicalaccess/plugins/cryptolib/include/logicalaccess/crypto/rsa_key.hpp:188:13: erreur: cannot convert ‘const boost::shared_ptr<rsa_st>’ to ‘bool’ in return
      return d_rsa;
             ^
```
Et sous FreeBSD avec Clang/LLVM 3.3 ça donne une erreur qui semble venir de la jeunesse du compilo. Faut que je regarde de plus près avec d'autres compilateurs et environnements.
- [^] # Commentaire supprimé
  
  Posté par Anonyme le 16 juillet 2013 à 21:29. Évalué à 1. Dernière modification le 20 janvier 2022 à 21:14.
  
  Ce commentaire a été supprimé par l’équipe de modération.
  - [^] # Re: Sa compil pa
    
    Posté par Maxime C. le 16 juillet 2013 à 23:21. Évalué à 1.
    
    Ah intéressant pour FreeBSD, à patcher donc :)
    Sous Fédora par contre ça semble venir d'un changement sur les smarts pointers qui nécessitent à présent une conversion explicite pour l'opérateur bool (voir erreur similaire sur StackOverflow).
    Dans un premier temps définir BOOST_NO_CXX11_EXPLICIT_CONVERSION_OPERATORS devrait contourner le problème de build, mais il est de bonne pratique de retirer la conversion implicite au profit de l'explicite. Du coup => nouveau ticket.
  - [^] # Re: Sa compil pa
    
    Posté par David Demelier (site web personnel) le 17 juillet 2013 à 09:21. Évalué à 0.
```
 elseif (UNIX)

-  target_link_libraries(liblogicalaccess logicalaccess-cryptolib crypto boost_filesystem boost_date_time boost_system dl)
+  target_link_libraries(liblogicalaccess logicalaccess-cryptolib crypto boost_filesystem boost_date_time boost_system)
 endif()
```
    Es-tu sûr que ça continue de compiler avec Linux en enlevant la bibliothèque dl ? Il me semble que sur Linux contrairement aux *BSD les fonctions dl* ne sont pas directement exportés dans la libc
    
    git is great because linus did it, mercurial is better because he didn't
    - [^] # Re: Sa compil pa
      
      Posté par Anonyme le 17 juillet 2013 à 09:51. Évalué à 1. Dernière modification le 17 juillet 2013 à 09:56.
      
      Non justement.
      
      Je n'ai pas trouvé (ni beaucoup cherché) de moyen pour demander à CMake d'ajouter/retirer ce qui ne va pas en fonction de l'OS.
      
      Cependant, lors de la création d'un port on pourrait très bien considérer le fait de patcher le fichier CMakeLists.txt. Le reste du code (defined(FreeBSD, ce genre de chose et par exemple d'éventuelles #includes manquantes, etc) par contre c'est pour facilité le portage, pour peu qu'upstream, on en ai quelque chose à faire.
      
      Apparemment ça a été prit en considération, c'est cool.
      
      Maintenant si on peut faire en sorte d'avoir les bons link dès le début, c'est mieux :)
      - [^] # Re: Sa compil pa
        
        Posté par Anonyme le 17 juillet 2013 à 10:07. Évalué à 1.
        
        Bon voilà j'ai trouvé quelque chose qui devrait fonctionner. Pas testé sous GNU/Linux encore.
        
        [^] # Re: Sa compil pa
        
        Posté par zul (site web personnel) le 17 juillet 2013 à 16:00. Évalué à 4.
        
        La bonne façon de faire avec cmake c'est d'utiliser la variable CMAKE_DL_LIBS, qui contient ce qu'il faut selon la plateforme (rien, dl, …).
        
        [^] # Re: Sa compil pa
        
        Posté par Anonyme le 17 juillet 2013 à 18:18. Évalué à 2.
        
        Ah très bon ! Merci.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.