Créer sa propre (mini) PKI | Artisan Numérique
▻http://artisan.karma-lab.net/creer-sa-propre-mini-pki
Tuto que j’ai suivi pour faire mes #certificats #ssl. À garder sous le coude(Permalink)
Créer sa propre (mini) PKI | Artisan Numérique
▻http://artisan.karma-lab.net/creer-sa-propre-mini-pki
Tuto que j’ai suivi pour faire mes #certificats #ssl. À garder sous le coude(Permalink)
The lie of the API | Ruben Verborgh
▻http://ruben.verborgh.org/blog/2013/11/29/the-lie-of-the-api
Futuristic? It’s not: it works already, and it’s really simple. Here is a designer chair from the Cooper-Hewitt museum:
▻http://collection.cooperhewitt.org/objects/35460799
The cool thing is that machine clients use the same URL to access a JSON version:
curl ▻http://collection.cooperhewitt.org/objects/35460799 -H “Accept: text/html”
curl ▻http://collection.cooperhewitt.org/objects/35460799 -H “Accept: application/json”
Not only does this enable to share URLs between different parties, it also makes access really simple. I don’t have to read the manual. Instead, I just use the same interface I use every day: the URL. Works the same way everywhere.
This technique is called content negotiation and it is a characteristic of REST APIs.
Voui voui voui. Chouette article qui met la pile aux gens qui compliquent à loisir.
#API #REST #content-negotiation #mime-type #HTTP #URL
Mais souvent pour faciliter les clients, c’est plus facile de leur faire passer des paramètres en get ou post que de leur demander de savoir gérer les entêtes HTTP. Enfin j’avais l’impression. (Moi-même étant assez nul en connaissance d’entêtes HTTP au passage.)
URLs identify concepts, and each URL can have multiple representations. This means that a single resource can be identified with one URL for all clients . Each client just indicates to the server whether it wants HTML or JSON or something else, and the server replies with a representation the client understands.
This lack of knowledge comes from developers being all too familiar with the programming-oriented environment they usually work with, but mostly oblivious about the resource-oriented nature of the Web.
The Web is an information space , not a programming space.
I imagine that developers were approached with the question “can you build an API?” And this is what they did.
But the question was wrong. It should have been: “ can you add machine access ?”
Un argumentaire très détaillé de Bruce Perens (un type important du monde du logiciel libre) contre les mesures techniques anti-NSA et notamment contre le chiffrement systématique envisagé, par exemple, par l’IETF ▻http://seenthis.net/messages/191453 .
Je ne suis pas d’accord du tout mais c’est un intéressant résumé des arguments anti-chiffrement (même s’il charge un peu la barque, y compris en citant le réchauffement planétaire).
▻http://perens.com/works/ietf/perpass/appropriate-response/01.pdf
#chiffrement #NSA #vie_privée #HTTP
@Fil Aucune idée. La fondation Wikimédia n’est pas citée dans les documents Snowden. Mais comme c’est une organisation états-unienne, je pense qu’elle n’aurait pas le choix et que l’analyse juridique théorique de Perens est correcte ici. À quand un déménagement de la Fondation vers l’Islande ou le Vénézuela ?
@Fil Les prises de position officielles de la fondation Wikimédia sont là : à propos de PRISM ▻https://blog.wikimedia.org/2013/07/18/wikimedia-foundation-letter-transparency-nsa-prism et plus généralement sur la vie privée lorsqu’on lit Wikipédia ▻https://blog.wikimedia.org/2013/09/03/wikimedia-privacy-policy-community-input
Et un long débat sur LinuxFr sur cet article de Perens ▻http://linuxfr.org/users/bortzmeyer/journaux/bruce-perens-contre-le-chiffrement-systematique
Internet architects propose encrypting all the world’s web traffic (Wired UK)
▻http://www.wired.co.uk/news/archive/2013-11/15/encrypting-all-web-traffic
HTTPv2 tout chiffré. Intéressant. À suivre...(Permalink)
Requests for PHP
▻http://requests.ryanmccue.info
Despite PHP’s use as a language for the web, its tools for sending HTTP requests are severely lacking. cURL has an interesting API, to say the least, and you can’t always rely on it being available. Sockets provide only low level access, and require you to build most of the HTTP response parsing yourself.
We all have better things to do. That’s why Requests was born.
Des requêtes #http en #php sans #curl... Cela m’aurait bien aidé il y a quelques années ;-)
Ya le module de Symfony aussi, sinon :
▻http://symfony.com/fr/doc/current/components/http_foundation/introduction.html#requete
@fil je serai plutôt d’avis d’intégrer tel quel le module « HTTP Foundation » de #Symfony. Il est totalement indépendant (mais il nécessite PHP >=5.3 par contre). On peut garder nos anciennes fonctions pour compatibilité, en mappant.
On a plein de projets qu’on n’avance pas ou très peu : essayons de maintenir uniquement ce qui est spécifique à SPIP.
Guzzle | #php HTTP client and #framework for consuming RESTful web services — Guzzle 3.0.0 documentation
▻http://guzzlephp.org
Guzzle takes the pain out of sending HTTP requests and the redundancy out of creating web service clients. It’s a framework that includes the tools needed to create a robust web service client, including: Service descriptions for defining the inputs and outputs of an API, resource iterators for traversing paginated resources, batching for sending a large number of requests as efficiently as (...)
#rest
Le 12 octobre, atelier-café sur la protection des communications pour les nOObs à Montreuil
▻http://simplonco.tumblr.com/post/61656772515/cafe-vie-privee-1-simplonco-surfez-chattez
Un article récent faisant le point sur la gestion des #erreurs dans une appli #REST, #JSON ou #Atom par exemple. Trouvé par @denisb.
SOA Bits and Ramblings : #Error handling considerations and best practices
▻http://soabits.blogspot.fr/2013/05/error-handling-considerations-and-best.html
A recurring topic in REST and #Web #API discussions is that of error handling ; what information should be included in error responses, how should #HTTP status codes be used and what media type should the response be encoded in?
How would the client know how to decode the error response payload? Actually this seems like an unanswered question for ATOM since the spec is rather vague about this point
Ceci car je posais la question de savoir quoi renvoyer comme contenu (pas l’entête avec le code de statut quoi) lorsqu’une application #AtomPub (#APP) doit renvoyer une erreur (par exemple lorsqu’on veut accéder à une ressource précise qui n’existe pas, ou qu’on a pas les droits). En JSON c’est « facile » : il n’y a pas de norme sur son contenu, on met ce qu’on veut dedans suivant l’application, puis on le documente. Mais en ATOM c’est déjà normé, et on ne sait pas ce qu’on doit faire si une erreur arrive.
L’auteur fait un lien vers une proposition de nouveaux types MIME pour ça : « error+json » et « error+xml », qui seraient à utiliser pour n’importe quelle API basée sur HTTP.
▻https://tools.ietf.org/html/draft-nottingham-http-problem-03
une colle #http : pourquoi #curl ne parvient-il pas à récupérer l’url suivante, alors que #lynx ou #firefox y arrivent ?
(utilisant curl -v je vois qu’il échoue au bout de n redirections sur un domaine www10 inexistant…)
(URL : ►http://opinionator.blogs.nytimes.com/2013/07/14/how-intellectual-property-reinforces-inequality)
octo-juk-3:euler-lua julienkirch$ curl -v “►http://opinionator.blogs.nytimes.com/2013/07/14/how-intellectual-property-reinforces-inequality”
About to connect() to opinionator.blogs.nytimes.com port 80 (#0)
Trying 170.149.168.153...
connected
Connected to opinionator.blogs.nytimes.com (170.149.168.153) port 80 (#0)
> GET /2013/07/14/how-intellectual-property-reinforces-inequality/ HTTP/1.1
> User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8x zlib/1.2.5
> Host: opinionator.blogs.nytimes.com
> Accept: /
>
< HTTP/1.1 303 See Other
< Date: Sun, 11 Aug 2013 13:59:45 GMT
< Server: Apache
< Location: ▻http://www.nytimes.com/glogin?URI=http://opinionator.blogs.nytimes.com/2013/07/14/how-intellectual-property-reinforces-inequality/&OQ=_rQ3D0&OP=b7574667Q2FQ7DQ3B)Q3DQ7Df3yQ7DwwwQ7DQ3CyQ2AGQ7DzQ26Q7Bm
< Content-Length: 0
< Content-Type: text/plain; charset=UTF-8
<
Connection #0 to host opinionator.blogs.nytimes.com left intact
Closing connection #0
curl -v “▻http://www.nytimes.com/glogin?URI=http://opinionator.blogs.nytimes.com/2013/07/14/how-intellectual-property-reinforces-inequality/&OQ=_rQ3D0&OP=b7574667Q2FQ7DQ3B)Q3DQ7Df3yQ7DwwwQ7DQ3CyQ2AGQ7DzQ26Q7Bm”
About to connect() to www.nytimes.com port 80 (#0)
Trying 170.149.168.130...
connected
Connected to www.nytimes.com (170.149.168.130) port 80 (#0)
> GET /glogin?URI=▻http://opinionator.blogs.nytimes.com/2013/07/14/how-intellectual-property-reinforces-inequality/&OQ=_rQ3D0&OP=b7574667Q2FQ7DQ3B)Q3DQ7Df3yQ7DwwwQ7DQ3CyQ2A HTTP/1.1
> User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8x zlib/1.2.5
> Host: www.nytimes.com
> Accept: /
>
< HTTP/1.1 302 Found
< Date: Sun, 11 Aug 2013 14:00:05 GMT
< Server: Apache
< Set-Cookie: NYT-S=0MdwwKEzk0V1PDXrmvxADeHwoJrgcFjUKAdeFz9JchiAIUFL2BEX5FWcV.Ynx4rkFI; expires=Tue, 10-Sep-2013 14:00:05 GMT; path=/; domain=.nytimes.com
< Location: ▻http://opinionator.blogs.nytimes.com/2013/07/14/how-intellectual-property-reinforces-inequality/?_r=0
< Content-Length: 0
< Cneonction: close
< Content-Type: text/html; charset=UTF-8
<
Connection #0 to host www.nytimes.com left intact
Closing connection #0
curl -v —cookie “NYT-S=0MdwwKEzk0V1PDXrmvxADeHwoJrgcFjUKAdeFz9JchiAIUFL2BEX5FWcV.Ynx4rkFI; expires=Tue, 10-Sep-2013 14:00:05 GMT; path=/; domain=.nytimes.com” "▻http://opinionator.blogs.nytimes.com/2013/07/14/how-intellectual-property-reinforces-inequality/?_r=0"
About to connect() to opinionator.blogs.nytimes.com port 80 (#0)
Trying 170.149.168.153...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 —:—:— —:—:— —:—:— 0* connected
Connected to opinionator.blogs.nytimes.com (170.149.168.153) port 80 (#0)
> GET /2013/07/14/how-intellectual-property-reinforces-inequality/?_r=0 HTTP/1.1
> User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8x zlib/1.2.5
> Host: opinionator.blogs.nytimes.com
> Accept: /*
> Cookie: NYT-S=0MdwwKEzk0V1PDXrmvxADeHwoJrgcFjUKAdeFz9JchiAIUFL2BEX5FWcV.Ynx4rkFI; expires=Tue, 10-Sep-2013 14:00:05 GMT; path=/; domain=.nytimes.com
>
< HTTP/1.1 200 OK
< Date: Sun, 11 Aug 2013 14:01:13 GMT
< Server: Apache
< Pragma: no-cache
< Cache-control: max-age=238, must-revalidate
< Vary: Cookie
< Last-Modified: Sun, 11 Aug 2013 14:00:11 GMT
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=UTF-8
<
WIN
moi j’ai le même problème avec les doc sur github
irrécupérable par curl :(
Where did all the HTTP referrers go? (Cyril Aknine)
▻http://smerity.com/articles/2013/where_did_all_the_http_referrers_go.html
Source : Smerity.com
CMIS - Wikipédia
▻https://fr.wikipedia.org/wiki/CMIS
CMIS fourni un #modèle-de-données commun couvrant les types de fichiers et répertoires avec des propriétés génériques pouvant être lues ou écrites. CMIS décrit aussi un système de gestion des droits d’accès, de contrôle de version et offre la possibilité de définir des relations génériques. Il dispose d’un ensemble de services pour modifier ou interroger le modèle de données et peut être utilisé par plusieurs protocoles comme #SOAP et #REST à l’aide de la convention #Atom. Le modèle est basé sur des architectures communes de systèmes de gestion de #documents.
Une idée pour #spip ?
Aucune implémentation PHP de la partie serveur à ma connaissance, ça risque d’être très compliqué, pour un gain qui reste à prouver…
▻http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services#CMIS_Servers
Il y a sans doute plein d’autres chantiers plus importants dans SPIP… ;-)
#idée_pour_spip, même.
En ce qui me concerne, je vais peut-être devoir coder cette année un serveur #AtomPub (#APP) complet pour SPIP. Donc gérer des collections d’objets (articles, événements, patates) en #REST avec les méthodes #HTTP, en lecture ("facile") et surtout en écriture.
HTTP: The Protocol Every Web Developer Must Know – Part 2
▻http://net.tutsplus.com/tutorials/tools-and-tips/http-the-protocol-every-web-developer-must-know-part-2
In my previous article, we covered some of HTTP’s basics, such as the URL scheme, status codes and request/response headers. With that as our foundation, we will look at the finer aspects of HTTP, like connection handling, authentication and HTTP caching. These topics are fairly extensive, but we’ll cover the most important bits.HTTP …
Source: Web development tutorials, from beginner to advanced
Use //
instead of http://
or https://
: HTTP client will use whatever protocol the page was fetched with - ▻https://news.ycombinator.com/item?id=5514784 #SSL #HTTP #HTTPS
Alternatives IFTTT
▻http://bouclans.net.free.fr/osyn/index.php?2012/11/27/15/02/23-alternatives-ifttt
Pistes à étudier
Source : Bouclans.net - Eric
#étudier #être #action #admin #admin #administration #alternative #alternatives #automatisation #bien #blank #blog #bonne #cherchant #cityfacts #cityfactsrc #code #compliquée #créer #cron #daemon #deri #deri #fameux #html #http #ifttt #images #incron #incron #inotify #linux #linux #mais #pipes #piste #pistes #pour #présentation #propres #recettes #semble #service #stories #target #tomber #trouvé #utilisation #viens
JSON Web Token (JWT)
▻http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html
JSON Web Token (JWT) is a compact URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JavaScript Object Notation (JSON) object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or MACed and/or encrypted.
Si je comprends bien, c’est pour envoyer des données entre deux services, ou un serveur et un client, de manière sécurisée, mais sur #http ?
J’ai pas complétement fouillé (je le seen pour y revenir) mais grosso modo c’est une façon d’échanger un token sécurisé (qui vient vérifiablement d’une partie) en utilisant JSON. Ça sert notamment à faire du proof-of-purchase.
#seenthis_bug , le client #oembed utilisé ne marche pas avec #HTTPS ?
RFC 6797 : HTTP Strict Transport Security (HSTS)
La technique #HSTS (HTTP Strict Transport Security), normalisée dans ce #RFC (mais déjà largement déployée) vise à résoudre une attaque contre #TLS. Si un site Web est accessible en #HTTPS, et qu’un méchant arrive à convaincre un utilisateur de se connecter en HTTP ordinaire à la place, le méchant peut alors monter une attaque de l’homme du milieu. Le fait que le site soit protégé par TLS n’aidera pas dans ce cas. Pour éviter cette attaque, HSTS permet à un site de déclarer qu’il n’est accessible qu’en HTTPS. Si l’utilisateur a visité le site ne serait-ce qu’une fois, son navigateur se souviendra de cette déclaration et ne fera plus ensuite de connexions non sécurisées.
►http://www.bortzmeyer.org/6797.html
Ça serait cool pour améliorer la sécurité de SeenThis mais, de toute façon, il faudrait d’abord résoudre <►http://seenthis.net/messages/98342>
Permettre un accès en #HTTPS à Seenthis, c’est très cool (pour les lecteurs situés dans des pays dictatoriaux, ou qui travaillent dans une entreprise qui flique ses salariés, c’est même recommandé par l’EFF). Mais il faudrait un certificat plus sérieux. Mon Firefox me dit :
« The certificate is not trusted because it is self-signed. »
Il faudrait utiliser une AC comme CAcert ou StartSSL ou autre.
« The certificate is not valid for any server names. »
Et, en effet, aucun nom de serveur n’est indiqué dans le certificat.
« The certificate expired on 01/12/12 16:37. The current time is 11/20/12 10:41. »
Il faudrait renouveler le certificat (truc : CAcert envoie un rappel automatiquement)
#SeenThis_bug #TLS #X.509
Je trouve que c’est de toutes manières inutilisable, parce que les liens « Accueil » et « Seenthis » renvoient vers la version http.
je vote aussi pour une utilisation plus fluide avec #HTTPS. Et pourquoi pas une case à cocher dans les préférences pour être systématiquement redirigé vers la version https?
Et pourquoi pas installer ce plugin ?
▻http://contrib.spip.net/Rediriger-en-HTTPS-quand-l-utilisateur-est-connecte
J’ai regardé le code source de #seenthis pour voir comment régler l’histoire du passage en http quand on va sur « Seenthis » ou « Accueil » alors qu’on est en https, mais je vois pas ce qui permettrait de garder le https. A vrai dire je comprends pas pourquoi un #URL_AUTEUR garde le https, et non un #URL_SITE_SPIP...
▻http://trac.rezo.net/trac/seenthis/browser/squelettes/inc/entete.html
J’ai regardé un peu les offres commerciales.
Pour avoir juste le domaine, Gandi le fait pour 12 euros par an. ▻https://www.gandi.net/ssl/grid
Pour avoir des sous-domaines, (*.seenthis.org) y’a ▻https://www.namecheap.com/ssl-certificates/comodo/positivessl-wildcard-certificate.aspx qui le fait à $85.00 par an.
L’article de Otto, Sanchez, Rula et Bustamante, « Content delivery and the natural evolution of the DNS », est consacré à l’interaction entre les CDN et les résolveurs DNS publics. Un CDN (Content Delivery Network, comme Akamai) utilise souvent le DNS pour router une requête vers le serveur le plus proche de l’utilisateur. Par exemple, si la question DNS vient de France, on donne l’adresse IP d’un serveur en Europe. Les résolveurs DNS publics (comme Google DNS ou OpenDNS) cassent ce schéma puisque l’adresse du client, vue par les serveurs du CDN, n’a pas forcément de rapport avec la localisation du vrai client (le navigateur Web). Cet article est le premier à mesurer cet effet (on lit souvent des phrases comme « l’utilisation du résolveur DNS public XXX permet d’avoir des résolutions DNS plus rapides » mais c’est de la pure publicité, peu de gens ont mesuré).
►http://aqualab.cs.northwestern.edu/component/attachments/download/235
Si on est pressé, on peut sauter à la figure 7 de l’article : elle montre le délai de réponse HTTP pour deux CDN connus, Akamai et Limelight, avec utilisation d’un résolveur DNS local à la machine, celle des résolveurs DNS du FAI, celle de Google Public DNS et celle d’OpenDNS. On voit deux groupes : résolveur local et résolveur du FAI pour le premier et un groupe plus lent, les deux autres (les résolveurs publics). Bref, pour accéder à un CDN, le résolveur public est une mauvaise idée.
En utilisant l’extension DNS - pas encore normalisée - ECS (EDNS Client Subnet), que gèrent Google Public DNS et Akamai, les résultats sont meilleurs, sans toutefois rattrapper les valeurs obtenues avec le résolveur du FAI (figure 11). ECS est pour l’instant peu déployé et, comme toute extension DNS, posera peut-être des problèmes avec des « middleboxes » programmées avec les pieds.
Enfin, les auteurs proposent une solution à eux, qui nécessite de modifier le comportement du résolveur local (mais pas celui du résolveur public, ou du CDN, contrairement à ECS) : le résolveur local s’adresse aux résolveurs publics par défaut, mais interroge directement les serveurs DNS du CDN lorsqu’il détecte un CDN. (L’article est plutôt vague sur comment reconnaître un CDN, ils proposent une liste manuelle ou bien l’heuristique « s’il y a un CNAME, c’est un CDN ».) Leur solution a été mise en oeuvre dans le relais DNS namehelp.
#DNS #HTTP #OpenDNS #GooglePublicDNS #CDN
4 Simple Changes to Stop Online Tracking | Electronic Frontier Foundation
►https://www.eff.org/deeplinks/2012/04/4-simple-changes-protect-your-privacy-online
#publicité #tracking #surveillance #adblock+ #cookies #referers_off #https_everywhere
Très bon coup de gueule sur le délire de soi-disant #sécurité (en fait lié à un mélange de volonté de contrôle et de pure incompétence) qui fait qu’#HTTP est maintenant le seul protocole à passer partout, ce qui fait qu’on réinvente tous les protocoles au dessus de HTTP.
►http://jean-pierre-troll.blogspot.fr/2009/07/le-syndrome-http.html
Oui mais... l’intérêt de passer sur HTTP (pour moi) c’est aussi de pouvoir implémenter directement dans le browser, avec interface et tout.
Et accessoirement, c’est pas mort WS-* ?
@robin Si, WS-* a sombré avec d’autres délires de costard-cravate-Javaïsants. Mais il en reste plein à maintenir pour les pauvres ingés.
@robin Imaginons qu’on veuille faire de la messagerie instantanée depuis un navigateur Web. Développer un nouveau protocole d’IM au dessus de HTTP (qui n’est pas vraiment fait pour ça, cf. les websockets), puis programmer le truc dans le navigateur, est-il vraiment plus simple que d’ajouter un client XMPP dans le navigateur ?
ahah, pas mal le Jean-Pierre ! J’ai fait tourner le blog à quelques collègues Javaïstes (à regrets, et sans cravates), ils semblent avoir apprécié.
Un document de travail de l’#IETF s’attaque à cette question « Implications of running Internet over ports 80 and 443 » ►https://datatracker.ietf.org/doc/draft-blanchet-iab-internetoverport443
RFC 6698 : The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol : TLSA
À chaque seconde, d’innombrables transactions sur l’Internet sont protégées contre l’écoute et la modification malveillante par le protocole #TLS. Ce dernier est capable de chiffrer la session (pour la protéger contre l’écoute par un tiers) et d’authentifier le pair avec qui on parle (pour s’assurer qu’on n’est pas en train de communiquer avec un usurpateur). Comment TLS authentifie t-il ? La méthode la plus courante aujourd’hui est de se servir de certificats #X.509 vérifiés (en théorie) par une Autorité de Certification. Ce mécanisme repose sur une confiance aveugle dans de très nombreuses organisations, et a de nombreuses faiblesses, comme on l’a vu en 2011 où le piratage de plusieurs AC a permis à des attaquants d’obtenir de « vrais-faux » certificats, y compris pour des organisations qui n’étaient pas clientes des AC piratées. La démonstration étant ainsi faite que X.509 n’était pas digne de la confiance que certains lui accordent, il restait à concevoir une meilleure solution. Rendue possible par le déploiement de #DNSSEC, voici #DANE (DNS-based Authentication of Named Entities) et ses enregistrements #DNS #TLSA. DANE permet à chacun de publier de manière sécurisés ses certificats, bouchant ainsi les vulnérabilités de X.509, ou permettant même de s’en passer complètement.
DANE permettrait par exemple, d’accéder à SeenThis sans se faire engueuler par son navigateur. Aujourd’hui, SeenThis est accessible en #HTTPS mais avec un certificat auto-signé, et pour un nom invalide ("SeenThis" et pas "seenthis.net"). Ajouter un enregistrement TLSA à _443._tcp.seenthis.net permettrait de ne plus avoir d’avertissement de sécurité (pour les futurs navigateurs Web avec gestion de DANE/TLSA).
►http://www.bortzmeyer.org/6698.html
#RFC
Info importante apprise en visionnant les vidéos du CMS Day : #Drupal 8 va intégrer plusieurs des modules de base du #framework #symfony !
Le cœur qui implémente super proprement le standard #HTTP dans #PHP, le module de #route #routing pour faire correspondre masques d’#URL, actions HTTP, et action dans le logiciel, plein de trucs supers... qui vont être intégrés directement dans le noyau de Drupal.
Le but est de rajeunir un code vieillissant, de le rendre plus maintenable, plus testable et générique, et plus interopérable puisque le code sera partagé avec d’autres applis, ces morceaux ne seront plus propres à Drupal.
Je trouve cela extrêmement intéressant.
Le but n’est évidemment pas que tous les logiciels se ressemblent et gommer leur personnalité ou ce qu’ils pourraient apporter d’innovant.
En effet, ça intégrerait surtout des éléments bas niveaux, qui sont à priori des bonnes pratiques dans un contexte #REST, quelque soit ce qu’on en fait ensuite.
Voici l’annonce de #Fabien-Potencier, de Symfony :
Symfony2 meets Drupal 8 - Symfony
►http://symfony.com/blog/symfony2-meets-drupal-8
Et l’annonce de #Dries-Buytaert, de Drupal :
The future is a RESTful Drupal
►http://buytaert.net/the-future-is-a-restful-drupal
Des idées pour #SPIP 4 ?