Dec 15

+1 Scraper (PlusOneScraper)

Reading time: 2 – 3 minutes

Google +1
La nova inteficie web del Google Reader ha portat molta cua a les xarxes socials i als mitjans digitals en general. Quan ets usuario d’un servei cloud, i si aquest és gratuït encara més, has d’estar obert a tot aquest tipus de situacions. Obviament hi ha coses que es fan estrictament per millorar l’experiència d’usuari i d’altres per anar alineats amb l’estrategia de negoci de l’empresa que ofereix el servei, en aquest cas Google.

Doncs bé, en el meu cas no entraré a discutir les moltíssimes sorpreses agradables que m’ha portat la nova interficie, sinó que em centraré a solucionar un dels pocs problemes que m’ha portat la interficie. Abans disposava d’un botó ‘share’ que em generava un petit blog on es penjaben les noticies que jo compartia. A través d’aquell blog la que em seguia podia veure les notícies que anava destacant dels meus feeds i jo mateix podia subscriurem amb un programa de lectura d’RSS per la tablet o el mòbil i així podia atendra les lectures més llargues en diversos moments morts del dia.

El famós botó de ‘share’ ha estat substituit pel ‘+1′ que com molts ja sabeu s’usa en molts llocs, no només al ‘Google Reader’ sinó a moltíssims blogs als que no cal estar sindicat per fer un ‘+1′ als articles que ens agraden, a busquedes de google, etc. De fet, jo pronostico que amb el temps això del ‘+1′ s’extendrà fins a nivell insospitats. Així doncs, a priori la idea és molt bona el problema és que tot el que botem dient que ens agrada s’afegeix al nostres ‘stream’ de ‘Google Plus’ que a dia d’avui no disposa de fil RSS, amb tot el que això suposa com ja he indicat abans.

Tot llegint el blog de l’Enrique Danz resulta que ell també té aquest problema i l’han resolt amb un simple script de PHP que fa d’scraper sobre la llista de ‘+1′ que manté ‘Google Plus’. El codi és senzillíssim d’usar el col·loquem al nostre server LAMP li passem l’usuari de la nostre compte google i l’script ens treu un XML en format RSS amb tot el que hem marcat amb un ‘+1′.

Jun 20

httptunnel: TCP sobre HTTP

Reading time: 2 – 2 minutes

HTTPtunnel logo

Amb httptunnel es poden establir connexions TCP sobre un enllaç HTTP, és a dir, disposem de dues eines el htc i el hts, escencialment el que fa és:

  • hts: publica un port simulant un servidor HTTP al conectar-hi amb htc ens enviarà cap al HOST:PORT configurats
  • htc: es conecta a hts usant HTTP i simulant un client HTTP normal (ffx, crhome, ie, etc) però en realitat transporta paquets TCP en el payload de les queries, l’usuari pot conectar-se a un port local que es publica i que permet accedir al HOST:PORT al que ha conectat hts de forma transparent

Per fer una prova de concepte jo el que he fet és conectar el hts amb un servidor VNC, al costat del htc he connectat un client VNC i he accedit al VNC de forma totalment transparent, a més amb un sniffer he comprovat que els paquets que passeben per la xarxa eren paquets HTTP estàndards, i així era. Tan senzill com això:

server:
./hts -w -F 127.0.0.1:5900 1080

client:
./htc -F 2300 server:1080
vinagre localhost:2300

A més també suporta la possibilitat de fer-ho a través d’un proxy, això si aquest només esta suportat si és sense autenticació o amb autenticació bàsica. Així doncs, a partir d’això em venen al cap algunes millores interessants:

  • suportar autenticació Digest i NTLM.
  • permetre accés al tunel via stdin/stdout (així ho podriem usar amb SSH com a ProxyCommand).
  • poder connectar-se a un segon proxy en l’extrem remot, és a dir, hts no té l’enllaç pre-establert.
  • suportar SSL, així ens estalbiariem haver d’usar stunnel per simular HTTPs.

Mar 08

reDuh: TCP sobre HTTP

Reading time: 1 – 2 minutes

La idea es força simple es tracta de transportar un fluxe TCP sobre d’una connexió HTTP convencional, fiexeu-vos que en aquest cas no estem parlant de proxies ni similars. Sinó de paquets TCP+HTTP que en la part de dades del HTTP tornen a implementar TCP, si fessim un petit esquema seria algo així:

+----+----+------+------+-----+------+
|... | IP | TCP | HTTP | TCP | DATA |
+----+----+------+------+-----+------+

Si realment teniu aquest interés montar reDuh és realment senzill, de fet, suporta servidors amb JSP, PHP i ASP. En escència l’únic que fa és usar aquests protocols per re-obrir una connexió TCP. Així doncs, al servidor on montem aquesta eina hem de tenir certs privilegis per poder obrir sockets des d’un script.
L’eina no és massa recomanable si pensem tenir fluxes de dades molt intensos, per exemple, senssions VNC. Però funciona prou bé si el que volem és transportar una sessió SSH o similar.

Mar 05

Terminals via Web (CLI via Web)

Reading time: 2 – 2 minutes

En l’article sobre Turnkey Linux vaig parlar sobre shellinabox, doncs bé per coses de l’atzar he descobert que no és l’únic sistema que preten donar accés a una sessió de shell a través d’una pàgina web.

De fet, les tres eines que he trobat són realment bones, així doncs si algú en sap alguna cosa més sobre elles que m’ho digui perquè no sé amb quina quedar-me:

  • shellinabox: emula un terminal VT100 i es llença com un dimoni que dona accés al host local a través del port que escollim, pot treballar amb o sense SSL.
  • ANYTerm: també suporta SSL però treballa a través d’Apache recolzant-se amb mod_proxy.
  • AJAXTerm: inspirat en ANYTerm però molt més simple d’instal·lar, ja que només depèn de python, o sigui, que treballa com a dimoni en el sistema on volem tenir la shell.

Mar 05

Proxytunnel: connecta un socket a través d’un proxy HTTP i HTTPs

Reading time: 2 – 2 minutes

Descrirure tècnicament el que fa proxytunnel és força senzill, ja que l’únic que fa és connectar l’entrada i sortides estàndard a través d’un socket que va del client al servidor a través d’un servidor proxy HTTP o HTTPs; soportant autenticació de diversos tipus en el servidor proxy.
Gràcies a aquesta funcionalitat tan simple es pot aplicar en infinitat de llocs, per exemple, com a backend d’OpenSSH per tal de poder fer connexions SSH a través d’un proxy HTTP. Això si el proxy haurà de suportar el mètode CONNECT.
Un cop ha establert la connexió amb l’extrem desitjat publica un port a través del qual ens podem connectar a través d’un client TCP convencional i enviar/rebre dades de l’altre extrem del túnel.
Quan treballem sobre proxies HTTP aquests no poden fer inspecció de continguts de capa 7 sinó s’adonaran que el tràfic qeu es passa no és legítim, encanvi si fem el túnel sobre HTTPs això no e un problema ja que no es pode inspeccionar les dades que van per sobre de la capa 4 al anar xifrades.
També cal pensar que és habitual que si el mètode CONNECT, que ha de ser suportat pel proxy esta habilitat (cosa rara que passi) segurament estarà restringit a connectar-se al port 80, 8080 i 443 remots, com a molt. Així doncs, si el que volem és fer una connexió SSH el que hem de fer és publicar el servidor SSH per algún d’aquests ports.
Si esteu interessats en aplicar la solució de la connexió SSH sobre proxy HTTP/s ús recomano seguir el manual que hi ha a la pàgina: DAG WIEERS: Tunneling SSH over HTTP(S).

Jun 19

podcast 1×09: sistema de autentcació unificat (single-sign-on)

Reading time: < 1 minute

Perseguint el paradigme de la SSO dins de l'empesa avui intentaré explicar el següent esquema:

mapa d'autenticació single-sign-on

Disclaimer: si alguna cosa és incoherent o no funciona hem sap greu, he fet el que he pogut.

Jun 12

podcast 1×08: CAS, Central Authentication Server

Reading time: 3 – 4 minutes

L’objectiu d’aquest podcast és donar una visió conceptual del funcionament de CAS 2.0, un servidor d’autenticacions SSO (Single Sign On). Bàsicament esta orientat a usuaris d’aplicacions amb interficie Web. A movilpoint l’estem usant tal com vaig comentar al podcast 1×07.

La diferència entre 1.0 i 2.0 és que la versió 1.0 només podia autenticar usuaris contra aplicacions web i aquests serveis no podien autenticar-se a la seva vegada contra altres serveis (serveis backend).

Amb l’esquema que hi ha a continuació i la previa lectura de les entitats d’un sistema CAS podreu seguir el podcast:


CAS - Central Authentication Server (schema)

A continuació descric les entitats que intervenen en un sistema CAS.

  • Service Ticket (ST): és una cadena de text que usa el client com a credencial per obtenir accés a un servei. Aquest tiquet s’obté del servidor CAS. La forma d’obtenir-lo és a través d’una cookie que es guarda al navegador.
  • Ticket Granting Cookie (TGC): cookie que s’envia al CAS quan un browser ja ha estat autenticat previament per aquest CAS, llavors aquest reconeix la cookie i li dona al browser un Service Ticket (ST) sense haver de passar el procés d’autenticació manual. Caduca en unes 8h aproximadament.
  • NetID: identifica a un ususari, el que coneixem habitualment com username.
  • ServiceID: identificador d’un servei, normalment en format URL.
  • Proxy Ticket (PT): és una altre cadena de text que usa un servei com a credencial per obtenir accés a un servei de backend. O sigui, que el primer servei per tal de desenvolupar la seva activitat li fa falta accedir a un altre servei (servei de backend), per tal d’obtenir accés a aquest darrer servei el primer usarà un proxy ticket. Aquest tiquets s’obtenen al CAS quan el servei que vol l’accés presenta un PGT (Proxy-Granting Ticket) i un identificador de servei que es refereix al servei de backend.
  • Proxy-Granting Ticket (PGT o PGTID): es tracta d’una altre cadena de text que com hem vist al punt anterior l’usa el servei per aconseguir un Proxy Ticket (PT) que li doni accés a un backend service l’accés a aquest servei serà amb les mateixes credencials que l’usuari original, o sigui, el que s’ha autenticat al primer servei.
  • Proxy-Granting Ticket IOU (PGTIOU): com no podia ser d’altre manera és una cadena de text que es passa com a resposta del serviceValidate i del proxyValidate usada per correlacionar un Service Ticket o una validació de Proxy Ticket amb un Proxy-Granting Ticket (PGT) particular.

Ara només queda escoltar el podcast:

Els enllaços relacionats amb el podcast:

NOTA: donar les gràcies al Marc Torres per la seva feina, gràcies nano.

Jun 11

gSOAP toolkit SOAP per C/C++

Reading time: 4 – 6 minutes

gSOAP, després de perdre-li la pista durant molt de temps aquesta llibreria de C i C++ crec que és la millor de codi obert i GPL que he trobat. Així doncs, ús la vull recomenar. El nom ve de “SOAP generator” i el va fer un professor, la versió 1.0 va sortir l’any 1999, per tant, podriem dir que l’eina esta més que provada si tenim en compte que va per la versió 2.7.1 que va sortir al gener del 2008.

Per entendre una mica que ofereix aquest toolkit esta molt bé fixar-se en aquest parell de gràfics que donen una visió de l’eina quan l’usem com a servidor SOAP:

gSOAP schema for server mode

i com a client SOAP:

gSOAP schema for client mode

Si haguessim de fer una llista de funcionalitats més detallada i tècnica em quedaria amb la que ofereix la pàgina de l’aplicació:

  • All-in-one package. Independence from third-party tools and libraries ensures successful builds and reliable runtime execution.
  • Open source with several license options.
  • gSOAP supports both pure ANSI C application development and mixed C/C++ application development.
  • gSOAP is the only toolkit that supports XML-to-C/C++ mapping for native C and C++ data types, which means that you can serialize your application data directly instead of having to use wrappers or SOAP/XML-specific data types. Any C or C++ data type can be serialized when it can be specified in a C/C++ header file (except unions). The toolkit automatically serializes pointer-based data structure graphs, including cyclic graphs and pointers to derived class instances to support polymorphism.
  • The toolkit follows the WS-I Basic Profile 1.0a compliance recommendations. It warns about potential interoperability issues before building a new Web service application, so you don’t have to go through another development cycle to make your services compliant. In addition, a report is available to check compliance.
  • Complete support for industry-standard Web services protocols SOAP 1.1/1.2 (RPC and doc/lit), WSDL 1.1, and UDDI v2. Supports XML schema with primitive XSD types, simpleTypes, complexTypes, extension, restriction, elements, attributes, groups, attributeGroups, and arrays (including polymorphic data types and SOAP 1.1 encoding of multi-dimensional sparse arrays). Extensive interoperability testing with other SOAP toolkits resulted in a toolkit release that has proven to be stable, robust, and reliable.
  • Supports SOAP-over-UDP, MIME (SwA), DIME (streaming), MTOM (streaming), HTTP1.0/1.1, IPv4, IPv6, RSS, XML-RPC, WS-Addressing, WS-Enumeration, and many other WS-* protocols.
  • Supports WS-Security: authentication, tokens, digital signatures (XML encryption will be added in the near future).
  • gSOAP is the only toolkit that implements streaming techniques for DIME and MTOM binary attachment transfers. It also supports SOAP with Attachements (SwA) Multipart/related MIME attachments.
  • Fast and efficient because gSOAP uses streaming XML parsing techniques. Typical round-trip SOAP service invocation latencies are below 1ms. Shown to be the fastest SOAP1.1/1.2 compliant C/C++ implementation available (wrt. most common uses we tested).
  • Very portable: Windows, Linux, Unix, Mac OS X, Solaris, HP-UX, AIX, FreeBSD, TRU64, Irix, QNX, VxWorks, MS-DOS. Also portable to handheld devices such as WinCE (Pocket PC), Palm OS, Symbian, and embedded Linux. Clients and server applications can be created that are under 100K with a total memory footprint under 150K.
  • The gSOAP WSDL parser automates server and client application development. gSOAP also generates WSDL documens to publish your services.
  • gSOAP Web Services and clients are just as easy to program as C# and JavaRMI, see How To section below.
  • Serialization of native C and C++ data types allows you also to store and retrieve application data from XML repositories.
  • Includes stand-alone HTTP/1.1 and HTTPS secure Web Server.
  • Offers Apache_mod, IIS, WinInet, CGI, and FastCGI interfaces.
  • Supports HTTP/1.1 POST/GET SOAP/XML messaging with compression, chunking, keep-alive, logging, and SSL encryption.
  • The gSOAP compiler can be conveniently integrated in an IDE. For example, MSVC++ 6.0 project examples with gSOAP integrated in MSVC++ are included in the gSOAP distribution for Windows.
  • Security: supports HTTPS and WS-Security. In addition, the source codes have been carefully written to avoid security holes such as buffer overruns. Also, gSOAP is open source which means that the gSOAP implementation can be verified.
  • gSOAP’s memory management uses garbage collection so (deserialized) data can be cleaned up without a hassle.
  • Company backup for support, licensing, and consulting.
  • Extensive documentation.

Jun 02

Pound: reverse proxy i load balancing

Reading time: 3 – 4 minutes

A través d’un howto de howtoforge he descobert aquesta eina anomenada Pound. Realment m’ha deixat impressionat per la seva simplicitat i potència al mateix temps. A més m’ha donat molt confiança saber que hi ha almenys un site processant 30M de peticions al dia, unes 600 per segon amb aquest aplicatiu. Aquest tipus de números sempre ajuden a donar confiança en les eines.

Doncs bé, l’eina bàsicament es dedica a capturar totes les peticions HTTP i HTTPs repartint-les després contra els servidors que té en el backend. En cap moment fa de caché ni res similar. Tot i que cal destacar la capacitat de poder fer de SSL wrapper. Així doncs, no cal que els backend facin de servidors SSL, només de servidor HTTP. Obviament pel client s’establirà una connexió HTTPs completament transparent. Si la validació SSL no és correcte Pound ja no envia peticions als servidors que té darrera.

Les funcions de balancejador de càrrega (load balancer) permeten no perdre les sessions establertes pels navegadors dels clients contra els servidor de backend, de fet, Pound implementa sis formes diferents de capturar una sessió per tal de no enviar peticions a un dels backends que no conegui la sessió del navegador.

Suporta funcions de fail-over, així doncs totes les peticions es direccionen només als servidors de backend que se sap que funcionen, la validació que es fa per saber si un servidor esta actiu o no és força simple i a grans trets es basa en paquets ICMP.

Finalment també cal destacar una funcionalitat que m’ha cridat molt l’atenció, ja que permet fer de wrapper d’URL i enviar les peticions que acompleixin certes expressions regulars cap a un o altre servdidor. Això permet, per exemple, enviar els dominis virtuals cap a un o altre servidor. A més, també podem per exemple, enviar les peticions d’imatges cap certs servidors de backend específics.

Al llegir-me la documentació d’aquesta eina el que més m’ha intrigat és saber com resolien el típic problema que presenten les eines d’aquest tipus, els fitxers de logs. M’explico, una cosa molt important a poder controlar des del punt de vista d’un servidor web és saber d’on arriben les peticions si el servidor web no rep les peticions directes d’internet sinó a través d’un balancejador com Pound la IP origen de la petició es perd i per tant, els fitxers de logs dels servidors web no són reals sinó que tenen com a origen sempre el balencejador. A més de totes els problemes associats a no saber d’on venen les peticions, com el control d’accés i d’altres similars.

Doncs bé, bàsicament això es soluciona a través d’una capçalera HTTP afegida des de Pound a la petició web. Així doncs és en aquesta capçalera que s’han d’anar a buscar les dades necessaries per recomposar el fitxer de logs del servidor web. També hi ha mod’s d’apache que ja solucionen aquest tema directament capturant aquesta nova entrada en la capçalera HTTP, concretametn val la pena que no perdeu de vista mod_extract_forwarded2.

Sota el meu punt de vista un gran descobrint i una eina molt interessant per tal de poder montar servidors web’s amb més cara i ulls. No sé si algú l’haura provat ;)

Mar 27

python trick: compartir directori via HTTP

Reading time: 1 – 2 minutes

A vegades estant en la propia LAN, suem tinta per dir-li a un usuari de windows com ho ha de fer per agafar un fitxer d’un directori del nostre linux. Si teniu python instal·lat, normalment totes les distribucions l’instal·len per defecte a més del paquet HTTP. Podeu fer una cosa tan simple com posar al .bashrc:

alias quickweb='python -c "import SimpleHTTPServer;SimpleHTTPServer.test()"'

Ara aneu al directori on voleu compartir els fitxers i escriviu: quickweb. Això obrirà el vostre port 8000 i qualsevol usuari de la xarxa podrà connectar-se amb el navegador a la vostre IP pel port 8000. Allà es pot veure i descarregar els fitxers que hi teniu. Quan volgueu deixar de compartir el directori només cal fer un Control+C i llestos.

Realment una xorrada molt i molt útil, no? si voleu comprovar què esteu compartint ja ho sabeu: http://127.0.0.1:8000. Més senzill impossible.