03.05.09
Posted in agile, igalia at 12:51 am by pinowsky
Last Thursday I got the opportunity of attending Software Craftsmanship 2009, a conference about agile methodologies and test-driven development.
The conference was divided in three tracks, many of them happening at the same timing on different rooms. I attended the following:
Three paradigms: Taking An Extreme Position on Code Style in a Safe Environment by Keith Braithwaite
A series of three short exercises to be done on an existing base of source code, a small project comprised by a data provider, a controller and a data transfer object. For each exercise, Keith give the audience some time to bang their heads and reach to some kind of conclusion. After that, people discuss about the solutions proposed. Of course, none of these changes could break the logic of the program, that means basically, do not break the tests. It was my impression that the bottom line of the exercise was to show that unless you do not break the test whatever change you make in a program is still valid (for the better or for the worse). It was also my impression that there was not definitive answers.
TDD As If You Meant It by Keith Braithwaite
On this talk Keith proposed a small problem to be solved: considering the Japanese board game Go, write a program to determine when a stone is in an atari state. Perhaps the problem was the less interesting thing, here the point was solving the problem following a test-driven development way. First,write a test that fails, add some implementing code to make it run, later move that implementation code to a class when you have enough code. Here the audience was asked to paired with someone else. I got to recognize that my experience on TDD is very limited, but I was lucky to pair with someone with more experience than me. The interesting thing was that although most everyone recognized to do TDD on their daily basis, they found the task very complicated, since they tend somehow to approach testing in other ways, not starting from the root of the problem they want to solve. This was truly TDD as you meant it, an eye-opener seminar.
Empirical Experiences of Refactoring in Open Source by Steve Counsell (Brunel University).
It was a lecture about refactoring in open source, a project carried at Brunei University. Firstly, Steve started defining the term of code smell. A term coined by Kent Beck to mean “a surface indication that usually corresponds to a deeper problem in the system”. Later Martin Fowler would pointed out several refactoring tasks you can do on a project to reduce code smell. Steve used this tasks as metrics and with the help of a tool developed at Brunei university, they managed to gather some statistics and conclusions on 10 to 15 java open-source projects. Someone in the audience asked if this tool was also open-source. It seems it was never freed but Steve seemed opened to doing it.
5 Reasons To Have A Coding Dojo At Your Company by Ivan Sanchez.
Ivan explained the concept of a coding Dojo, and immediately after we got a hands-on Dojo. We worked on an existing source code base, two people paired and carried the development of the program for over 5 minutes. The audience could suggest solutions, shorcuts, whatever. When the time expired, the driver left, and another member of the audience come in.
Unluckily I missed Programming In The Small by Ivan Moore & Mike Hill . It was my first time in London, and despite leaving early in the morning I found myself lost in the tube on my way to the BBC Media Center.
Anyway, it was a very good conference. The atmosphere was of excitement and at the end of the day it seemed people was waiting for more. I wish I had a deeper knowledge on TDD and could have taken more advantage of the seminars, but I could at least grasp the basics and participate. It has broaden my mind on TDD so my expectations are fulfilled on that sense.
Lastly, I would like to mention the splendid organization of the event (catering service included), the caring of Jason Gorman and colleagues who help him on the organization and the support of the BBC and its Backstage strategy. After the event, the BBC kindly invited us to a tour at the television center. Although I missed my chance of having myself spot close to Doctor Who’s tardis, I enjoyed very much the pints at the BBC Club and the chatting with the guys from Songkick and other BBC IT workers.
It seems very likely there will be a next edition next year, but perhaps bigger. Don’t miss out!
PS: In case you want to learn more check the summary video by Jason on YouTube!
Permalink
02.25.09
Posted in agile, igalia at 12:03 am by pinowsky
Next Thursday 26th I will be attending Software Craftsmanship, hold at the BBC Media Center in London.
It’s a one-day event about how to build software the right way, as the own conference’s motto states. Most of the speakers, rather say all of them, have an extensive background on eXtreme programming. Some of them, as Ivan Moore or Keith Braithwaite, are in fact well-known speakers at some of the most important conferences on Agile methodologies as Agile 2008, or Qcon.
What attracts me the most is the practical approach of the programme, where most of the speeches are actually seminars. In some of them, an exercise and a set of questions are proposed to the audience, then with the help of the speaker the audience should withdrawn their own conclusions and discuss about them. And there is always the chance to peer with somebody, what reinforces the importance of the role that Agile methodologies have in the whole conference.
Lastly, I wouldn’t like finishing this post without mentioning that Igalia has kindly covered most part of the expenses. As you may know, here at Igalia, every worker (from the second year on) got a pocket budget for training. This budget can be used to strengthen our knowledge on different areas we’d like to improve, ranging from technical things to business, finance, etc. On the other hand, accommodation will be fully covered by the brand-new apartment Igalia has rented in London. Thought in the beginning as a good way to help workers go abroad for improving their English, I think it can also be a good tool for many of us who would like to take advantage of the many conferences and events that are organize in London throughout the year.
This kind of policies show the high commitment of Igalia on training and education, something that I personally appreciate very much.
Permalink
02.16.09
Posted in uncategorized at 11:39 pm by pinowsky
Hace tiempo que no pasaba por este blog, de cuando, por un breve periodo de tiempo, empecé a mirar algo de .NET.
Es la cara burlona de Ian Marteens. Ian Marteens es conocido en el mundo hispano por haber escrito varios libros sobre tecnologías Microsoft: .NET, C#, ADO, etc, y anteriormente sobre Delphi. En el blog también suele intercalar artículos sobre el lenguaje de programación Freya, lenguaje desarrollado por él mismo, POV-ray, consultoría, etc.
Puede que al Sr.Marteens no le guste el software libre y el sistema operativo del pingüino (yo creo que no hay mayor libertad que la de dejar elegir a cada uno lo que más le gusta, dentro de los límites de la legalidad, se entiende), pero a mí sí me gusta su prosa, sus comentarios irreverentes, y sobre todo la sensación de estar leyendo a alguien que sabe muy mucho de lo que habla, y que además defiende sus posiciones con criterio.
Tal como relata el propio Ian en el blog, actualmente se encuentra preparando un libro sobre prácticas de desarrollo de software. Como aperitivo ha dejado una serie de tres posts bajo el encabezado “Los N pecados capitales”. Si el libro es la mitad de bueno que estos posts, probablemente pasé a la historia de mi estantería como el primer libro de informática (en español) por el que desenfundo un puñado de euros.
Me lo he pasado como un enano leyendo estas 3 verdades como puños, y otros tantos buenos posts y comentarios.
Permalink
02.10.09
Posted in agile, igalia at 12:04 am by pinowsky
I just finished reading Software Craftsmanship: The New Imperative (Addison-Wesley, 2002) by Pete McBreen.
Software Craftsmanship is a new attempt to define how great software should be developed, in contrast to the classical software engineering approach.
Pete McBreen sees that software engineering has borrowed many of the process, habits and terminology from the mechanical and manufacturing world.
Above all, for Pete, software developing is more of an intellectual, social task than it is a mechanical task. And that requires a new approach.
On the first chapters Pete takes a look at what is wrong with software engineering giving some background at the succession of events that have led software engineering on what it is today. Pete argues whether division of labor can really help software development or whether a ‘one-size-fits-all’ methodology really exists. This document is particularly insightful: Why they don’t practice what they preach?
After that, Pete introduces the concept of software craftsmanship. Software craftsmanship aims to create applications using small, highly skilled teams. Rather than attempt to build really large, monolithic applications, the craft approach seeks to build small applications that can then build on and enhance each other. However, software craftsmanship is not a replacement for software engineering, but rather a complement to it. In Pete’s words: “Scaling down software engineering to deal with smaller problems is just as hard as scaling up the craftsmanship approach and just as inappropriate”.
As in the old crafts, Pete borrows the metaphor of an Apprentice, learning from a Master, making his way to a Journeyman, and later, to a Master himself.
Coming to think on these terms Pete McBreen suggest the following principles that characterizes Software Craftsmanship:
- Small teams of good developers are more productive than large teams of average developers.
- Developing great software means paying attention to detail, as in old crafts.
- Do not focus on specialization. All members within the team, should understand the domain of the problem. There should not be anyone specialize in a specific part of the project, so then, no one is really indispensable.
- Code is reviewed by all developers, so as knowledge is spread among the team.
- Software should be developed as if it were to last 10 or 20 years.
- Maintenance should not be regarded as a low-level task, as taking over a project is proof worthing trust and respect.
- Take credit for your work.
- A master never leaves a project, as she takes credit for her work. Instead, it trains a successor.
- Perpetual learning.
- Constant communication with customers. Input from users is as important as the development process.
Many of the ideas suggested by Pete McBreen are in fact very similar to some of the ideas proposed by Agile methodologies: small groups, constant communication with clients, code review, etc. In fact that is something that the author himself states in the book:
“Agile Methodologies focus attention on the individuals in the software development team and the quality of their interactions with their customers and users. In doing so, they provide a good fit with software craftsmanship and another voice warning about the hazards of the software engineering approach. “
Other ideas proposed by Software Craftsmanship have been present within the free/open source communities from long time ago. The idea of taking credit for your work, spread the knowledge of an application among the team or the idea of training a worthy successor when the master leaves a project. Once again, Pete highlights these similarities in the book many times.
Although the idea is provocative and maybe need refinement I found the reading interesting. I liked very much the background exposed at the beginning, when McBreen established similarities between classical software engineering and industrial engineering. The idea of growing from apprentice to master seem to me more like a good metaphor of the path every engineer should take in their career, struggling for improving and continuously learning.
“Software development is meant to be fun. If it isn’t, the process is wrong“
Peter McBreen
Permalink
01.09.09
Posted in igalia, linux, mobile at 12:16 am by pinowsky
Recently I decided to switch my mobile phone supplier and move to other one with more competitive data transfer fees. Yesterday I got my new SIM card, and today I decided to try to connect to the internet using my mobile phone, a Nokia 6120c, as a modem.
Quique kindly helped me with the setup as we both got the same provider, and he is more experienced than me on doing this kind of things.
First step, was to install wvdial and configure /etc/wvdial.conf with the right options.I first tried:
# wvdialconf /etc/wvdial.conf
But no success. I finally end up copying verbatim a wvdial.conf file I found on this website. It was initially aimed for a N70, but other user reported the same setup also worked for a 6120c.
Later, I noticed that for using a USB port for serial communication I needed a special device /dev/ttyACM0, as it was demanded on the conf file.
Modem = /dev/ttyACM0
This node is created on-demand whenever a mobile phone is plugged into the laptop. However, I couldn’t find it on my filesystem. And that’s when the orgy of digging the internet and trying more and more weird commands started. I think we tried almost anything:
Create the node by hand:
# mknod /dev/ttyACM0 c 166 0
Add some lines to /etc/rc.local to create whenever the system boots.
If [ ! -e /dev/ttyACM0 ]; then
mknod /dev/ttyACM0 c 166 0
fi
Nothing of this worked. After that, we started trying loading different drivers:
# modprobe cdc_acm
# modprobe usbserial
# modprobe cdc_ether
Again, nothing worked. Then, I found an interesting thread on a forum where an user exposed the same symptons. At the end, I coudl find a reply where an user claimed to have solved the problem by changing the order of how modules are loaded. It’s supposed that cdc_acm should be more prioritary than usbserial. So, here I went again trying different combinations. Same result, no luck.
Then I took Quique’s phone, which successfully worked, and explore a bit what it did whenever it was plugged. I noticed that when the 6120 was plugged, the storage partition (SDcard) was automatically mounted, and that didn’t happen on Quique’s phone. We decided to remove the SDcard.
Finally, Quique took the phone and plug it on his laptop. It’s important to mention that when the 6120 is plugged, a menu with three options pops up. The option by default is to mount the SDCard (Data transfer), this is the option if no options is picked and the time expires. We leave it as usual, and then got an error since the Sdcard was no longer on the phone, so Quique went for the other option PC-Suite, and voila!
The bottom line of this is story could be something like it’s always much better going for a KISS approach rather than starting trying the most obscure linux commands that first come to your mind.
By the way, it’s no coincidence that in fact today I learnt that the last S of KISS stands for stupid, and that’s exactly how you feel after having spent two hours setting up a mobile phone for going on the internet, believe me.
Permalink
11.11.08
Posted in uncategorized at 11:52 pm by pinowsky
I just came back from holidays. I have spent almost the last month of October backpacking Eastern Europe together with a friend.
All started as a short visit to a friend of mine in Sofia. As 10 days in Sofia looked a relatively long period of time, visiting some other country nearby looked a fair deal. I then suggested Istanbul, as other Igalians highly recommend me to visit after having attended lastest GUADEC convention. But Servando fancy more Bucharest and Serbia, since he had never been there. We could not made up our minds, so we eventually chose both…Lastly, while arranging our flights we decided to make a 2-day stop in Rome (it was much cheaper flying low-cost from Spain to Sofia, via Rome for example, rather than taken a direct flight).
All in all, it was good. Now I am back with the batteries charged, and ready to catch up with work and the latests things on the web. More about my trip in my more personal blog (Spanish & English): The Bandarlog.
Permalink
10.05.08
Posted in google at 9:17 pm by pinowsky
This is an old topic. Google Reader is one of the few Google products which lacks an API. However, some people managed to reverse-engineering it almost three years ago. There is a well-know post (Google Reader API) from Niall Kennedy, former employee at Technorati, where he explained the underpinnings of Google Reader.
Comments on that same post are also interesting. One of them links to the docs of pyrfeed, a RSS/Atom framework which uses Google Reader as storage base. In my opinion, this is the best documentation I found so far about how the protocol works [1].
Interestingly enough, as some googlers admitted, Google Reader was in fact built upon its own API, that means the API came first, however, it has never been released. I believe that since it was one of the first Google products which was bound to an API, there was not a standarized way of doing things at that time, as an outcome, there are a few things which differ from other Google APIs. One of these differences, for example, is how to fetch an user authorization token, which is not based neither on ClientLogin or AuthSub.
Despite the completeness of pyrfeed documentation, I could tell from the comments on Nial Kennedy’s post, that there are still a few developers who do not know how to retrieve an authorization token, and how later, pass this token on requests which may need authorization, like getting a list of your feeds, managing them, or making a feed as starred. Let’s see how it works:
If you wish to perform an operation in Google Reader which requires authentication, you need to provide the following two tokens:
- SID (Session ID)
- Authentication token or T token (do not mix up this token with the Auth token you get by authenticating with ClientLogin)
There are also two ways of retrieving a Session ID token :
- If your browser (i.e Firefox) is opened and already logged in any Google site, a valid SID token would be stored in it. Firefox stores its session tokens inside sessionstore.js file. In conclusion, search for the SID inside sessionstore.js if there is any google session opened inside your Firefox.
- Authenticating against Google reader service using ClientLogin mechanism. Google reader service codename is reader. ClienLogin mechanism is fully documented by Google. ClientLogin mechanism returns three tokens, one of them is the SID token.
Once you got a valid SID token, do a GET request to the following URL to get a valid T token.
http://www.google.com/reader/api/0/token
Please notice that you should add the SID token as a cookie on this request, otherwise it would fail.
Once you get both tokens, SID and T, you can successfully perform any Google Reader operation which requires authentication (always pass these two values as cookies)
Finally, let’s review the whole proccess by examples:
1. First, get a valid SID token:
curl https://www.google.com/accounts/ClientLogin
-d Email=just_your_username_here_without_at_gmail_dot_com
-d Passwd=your_password_here
-d source=Google-cURL-Example
-d service=reader
Response:
SID=DQAAAH0AAAC0YHom0L5LDq10xGnbQK_O7OLiX3Qrou4XeA6P469shoM1goEFQT_zVn8YxDV38Y5v3mGJlhSzJuz5xLPqpKEM0Wedks-ak7LLpNjO7dZw779ljOQrC-2UCYFjiktJcfXmof7WeZs7O0SCNCQgPSKaENJ6FBTeDBeQLahUUrajrg
LSID=XXX
Auth=XXX
2. Once you get a valid SID, request a T token:curl -s -X GET http://www.google.com/reader/api/0/token –header “Cookie: SID=DQAAAH0AAAC0YHom0L5LDq10xGnbQK_O7OLiX3Qrou4XeA6P469shoM1goEFQT_zVn8YxDV38Y5v3mGJlhSzJuz5xLPqpKEM0Wedks-ak7LLpNjO7dZw779ljOQrC-2UCYFjiktJcfXmof7WeZs7O0SCNCQgPSKaENJ6FBTeDBeQLahUUrajrg”
Response:
kArWxxwBAAA.vegUbtUjv2Vvf_HKWlwjIA.QfhP1LoSb5ghYPz_AbOG_Q
3. Once you get a valid T token, perform any Google Reader operation you want, for instance, retrieve a list of your feeds
curl -s -X GET http://www.google.com/reader/api/0/unread-count?all=true –header “Cookie: SID=DQAAAH0AAAC0YHom0L5LDq10xGnbQK_O7OLiX3Qrou4XeA6P469shoM1goEFQT_zVn8YxDV38Y5v3mGJlhSzJuz5xLPqpKEM0Wedks-ak7LLpNjO7dZw779ljOQrC-2UCYFjiktJcfXmof7WeZs7O0SCNCQgPSKaENJ6FBTeDBeQLahUUrajrg; T=kArWxxwBAAA.vegUbtUjv2Vvf_HKWlwjIA.QfhP1LoSb5ghYPz_AbOG_Q” | tidy -xml -indent -quiet
Resources:
[1] pyrfeed, Google Reader API
Permalink
09.28.08
Posted in gadgets, google at 5:32 pm by pinowsky
If you had ever been curious about how to code a Google Internet Gadget, you most likely had put your hands on programming tools such as Google Gadget Editor for iGoogle.
I had coded a few gadgets so far. Although I didn’t spent much time with the editor, there were a couple of, let’s say features, I disliked getting the feeling that they were slowering down my work letting me be, in turn, less productive. Things like:
- Automatic refreshing, opened helloworld.xml sample to start coding my gadget, and stayed idle for a couple of minutes you get helloworld gadget refreshed throwing all your effort till then right to the dustbin.
- Cursor is set to first position of the text editor box after saving a file, super-inconvenient.
- On my Lenovo T61 laptop, pressing the key which is just left to the upper-arrow key, made the gadget to reload without confirmation. I know, this is more related to my own my settings, but cause me much headache (since it’s easy to rubber the key by chance when moving upwards)
- All the inconvenience of using any other text-editor when you are a Vim lover.
All this led me to code a command-line Perl script to upload a Google Internet Gadget to iGoogle.
There is not such a thing as an API for iGoogle to help programmers to interact with iGoogle, so all work has to be coded in an old-school fashion, pretending your script is in fact a browser and has to communicate with the iGoogle server in the same manner.
If you are a Perl programmer, you most likely be familiar with popular packages such as LWP (lib www Perl, although this acronym always reminds me to Larry Wall’s Perl). Client-Server HTTP communication defines a client as an user-agent, and that is all what LWP is about. First, instance a class called UserAgent, think of it as a XMLHttpRequest object is you are familiar with Javascript, then codify your http request, send and wait for a response.
Before stating coding, I used Wireshark, formerly known as Ethereal, to peer at how Firefox should interact with iGoogle. After that, the goal is to gathered all needed information iGoogle would expect from a browser request. The most difficult part here was to figure out were to get the SID cookie from.
Many of the cookies iGoogle expect from an HTTP request can be retrieved from your cookies.txt file (or querying moz_cookies table if you are using Firefox 3). All values stored in cookies.txt are permanent cookies. The SID cookie is in fact a session cookie, and by hence, should be stored in sessionstore.js file. You can also retrieve this value by successfully authenticating against Google using ClientLogin mechanism.
Summarizing, if your browser has an already opened Google Session, our script should peer at sessionstore.js file to fetch SID from it. If there is not a Google session opened within your browser, then our script should authenticate against iGoogle to get that specific value. Google ClientLogin mechanism is aimed just to retrieve a valid Auth token, necessary to interact with all Google’s services and APIs. The docs even claim that “SID and LSID are not currenly activated ans should not be used“, but here you see how this SID token can be used to successfully interact with Google’s services (upload files to iGoogle, Google Page Creator, etc) which lack an API.
Script to upload Google Internet Gadgets to iGoogle: download.
You need to set the following variables:
- username, you Google user name (without @gmail.com)
- password, your Google account password
NOTE: If a Google session is opened within your Firefox browser (that means, you are already logged in at least one Google service, when you use this script), then you can leave this two values empty.
- GG_ID (Google Gadget ID), every iGoogle user has a Google Gadget ID. To know your GG_ID, you must figure out what your target URL looks like. When the Save… option is pressed, Google Gadget Editor sent a POST request to a target URL whick looks like:
http://www.google.com/ig/gadgets/file/$GG_ID/$filename?synd=gde&et=itJbVyUh
Where:
- filename, is the name of file to upload
- GG_ID, is your Google Gadget ID.
Use Wireshark or Firebug to figure out what is the value for your GG_ID. Please, let me know if there is a better way to get this value.
Perl libraries required:
- POSIX
- DBI
- Data::Dumper
- Config::General
- LWP
NOTE: I tested this script on Firefox 3 (remember is needed to fetch cookies from whatever cookie store mechanism, sqlite3 in case of Firefox3). I added code to read cookies from cookies.txt (cookie store mechanism in Firefox 1 & 2), but haven’t tried it.
Permalink
08.23.08
Posted in firefox, google, web at 7:41 pm by pinowsky
Cookies are small pieces of data send by an HTTP server to an user agent (generally a browser) and sent back from the client to the server. In general, cookies are used for authentication, user tracking, maintaining user preferences, shopping carts. etc.
Cookies consist of a name/value pair set by a server by adding an extra header to an HTTP frame:
HTTP/1.1 200 OK
Content-Type: text/html; charset=ISO-8859-1
Location: blah:foo
Set-Cookie: PREF=bogus; domain=google.com
Consider a successful response received by a server. The domain www.google.com asks the user browser to set cookie PREF on save it for later use. All cookies previously set by a server, are sent back on subsequent requests.
Cookies were firstly thought as a mechanism for implementing persistence over HTTP communications. Since HTTP is a stateless protocol, there is no way to keep track of user interactions between different requests. HTTP protocol simply allows a browser to request a single document from a web server, without remembering who this client was. Cookies can be used to identify previous client connections, serving as the basics for implementing HTTP sessions.
There are two types of cookies:
- Session cookies, a temporary cookie stored in the user agent memory.
- Permanent cookies, used to store user’s preferences. Permanent cookies are stored in files and last for more than a session.
In Firefox, cookies are stored in ~/.mozilla/firefox/???.default/cookies.txt. Different browsers set a different limits for the amount of cookies a host can store. Firefox lets a domain to store up to 50 cookies per user, each up to 3-4Kbytes. You can view your cookies in Firefox by clicking on Edit->Preferences->Privacy->Show Cookies…
Netscape, and later Firefox till version 2.0, store permanent cookies in a file named cookies.txt. This file has the following file format:
.netscape.com TRUE / FALSE 946684799 NETSCAPE_ID 100103
Each line represents a cookie, composed by different fields separated by a TAB. From left-to-right this is what each field represents:
- domain, The domain that created AND that can read the variable
- flag, A TRUE/FALSE value indicating if all machines within a given domain can access the variable. This value is set automatically by the browser, depending on the value you set for domain
- path, the path within the domain the variable is valid for
- secure, A TRUE/FALSE boolean value indicating an https connection with the domain is valid to access the variable
- expiration, The UNIX time that the variable will expire on. UNIX time is defined as the number of seconds since Jan 1, 1970 00:00:00 GMT
- name, name of the variable
- value, value of the the variable
Imagine for a moment you log in Gmail by accessing to http://www.google.com. From there you are redirected to http://www.google.com/gmail, which set the following cookie in your browser.
.google.com TRUE /gmail TRUE 0 SID DXV9AAAA0G…
URL was split in two parts: domain and path, setting host to .google.com and path to /gmail, respectively. SID is in this case the name of this cookie, and very long string, DXV9AAAA0G…, its value. What’s more, flag is set to TRUE which means this cookie, SID, can be shared between different applications within the .google.com domain. The highest value a UNIX timestamp can represent is sometime in year 2038. Originally, Google cookies were set to this value, though to last more than 30 years from now. Privacy advocators complains have recently led Google to dramatically reduce theirs cookies’ lifespan to just 2 years [1] .Lastly, secure field is set to TRUE which means an https connection is required.
Firefox 3 features a SQLite3 database engine for storing permanent data such as user preferences, bookmarks, cookies, and many more. More specifically, cookies are stored in {profile_folder}/cookies.sqlite.
A quick glimpse to this database reveals a single table, named moz_cookies, with the following data structure:
CREATE TABLE moz_cookies (id INTEGER PRIMARY KEY, name TEXT, value TEXT, host TEXT, path TEXT,expiry INTEGER, lastAccessed INTEGER, isSecure INTEGER, isHttpOnly INTEGER);
Since cookies are now stored in a database, field order no longer is relevant.
- isHttpOnly, true if the cookie should only be sent to, and can only be modified by, an http connection.
- lastAccessed, is a new field indicating when was the last time this variable was accessed.
Conversely, session cookies are saved in a different file. Both Firefox 2 and Firefox 3 come with a built-in Session Store feature that saves your session data including open windows and tabs, window size and position, and text typed in forms. Session data is stored in the sessionstore.js file, located in your profile folder. So, in the example given above, SID (session id) cookie will be stored in sessionstore.js, rather than in cookies.txt or cookies.sqlite database.
In general, every web server sets a SID cookie whenever an user logs in successfully. Google, for instance, set a SID cookie in the user’s browser once he or she logs in, or programmatically by using some of Google’s authentication mechanism: AuthSub or ClientLogin (check my previous post: “Authenticating against Google services” to see how a successful ClientLogin response looks like.) Now it seems not difficult to figure out what that SID cookie actually meant, right?
References:
[1] The official Google Blog, Cookies: Expiring sooner to improve privacy, 2007
Marty Stepp, Cookies and Sessions, Web programming, University of Washington, 2007
David Whalen, The Unofficial Cookie Guide
Permalink
08.16.08
Posted in google, igalia, web at 12:25 am by pinowsky
Google provides two ways for authenticating third-party applications against Google services:
AuthSub is aimed to third-party web applications that may need to access an user Google service, such as Google Calendar, Picasa Web Albums, or other Google services. AuthSub authenticates an user via a proxy web page. Only when the service is about to use, the user is redirected to a Google’s authentication page for typing their credentials. Once the user has successfully logged in, the browser is redirected back to our web application.
On the other hand, ClientLogin was thought as an authenticating mechanism for standalone desktop applications, where redirecting to a web page may not be possible or does not make much sense. Users must rely on third-party applications to handle their Google user-name and password safely.
Let’s leave AuthSub aside and take a look at ClientLogin and how it works. First of all, before interacting with a Google service it is necessary to be authenticated against that precise service. ClientLogin is the mechanism we are going to use to do it so. It needs at least four parameters:
- Username, your Google’s account user-name (without @gmail.com)
- Passwd, your Google’s account password.
- service, the name of the Google service you want to use.
- source, and identifier for an application, composed of the following values: “Plugin - Application name - Version“;
Let’s compose an HTTP frame for authenticating against Picasa Web Albums
curl https://www.google.com/accounts/ClientLogin
-d Email=john.edwards
-d Passwd=newfoundland
-d source=Google-cURL-Example
-d service=lh2
If the authenticating process is success, that means, we got a 2XX status code back, the result would look something like this:
SID=DQAAAHwAAAB5Of1UNiExDVXQXhdZYcEafL_VnoCS8JzvZfAKjdWm__v_Ns5ncw_pahEEsB7-r5nZmMsZyK0HllSSxURV0k581VkzxHwxwvdy39nhRCTpBI1QhQOCSGvKH1tWufxZxqOxrUpS4x_hVLvfpbz7RjEO-8E7r37O6qOA3kfQK_pCVw
LSID=DQAAAH4AAAA1mBxyaM1-CjE8v3BiOEqXGVFBkQco_Z-c82rLBGNnxzy2bM9DI7riWv3-BTcqgoz7XCUum1i9yYCJSh4UHjI_v3_Kqy_N_Tx6j4ric0wI5cCYcMRQ-2C8nTKLQ17NtJEwd_Zm382DgS9-ryYXjfK05Lslj7nbl6a0TS4GZgTFbg
Auth=DQAAAH4AAAA1mBxyaM1-CjE8v3BiOEqXGVFBkQco_Z-c82rLBGNnxzy2bM9DI7riWv3-BTcqgoy1o9YW9tnUd98s3ILVDfUAILHfuqZsYWUbkiSAml2wsXNZJ8RMu8X6Jjigm4bPQEIjiR3nzV7mguDFIoEGRoiWAz0Uocy7PZU-BSNoLwP4Sg
As an outcome, we got three cookies or tokens. Among these three, the cookie labeled Auth represents the authentication token we are interested in, and should be used here after in every further interaction with the service. SID and LSID cookies are not currently active and should not be used (which is partly true, more on this in a coming post).
Several things to highlight before continuing:
- In general, while interacting with web services or composing hand-made HTTP frames is always a good idea to turn WireShark on for debugging.
- Notice that every Google service has its own identifier. In the example above, “lh2″ identifier stands for Picasa Web Albums service. A more detailed list of Google services and its code names can be found on this post: “Google Account Services Names”. Whenever we need to interact with a Google service is necessary to authenticate against that Google service. Right now, there is not such thing as single-sing-on mechanism for interacting with all Google services.
- Parameters are case-sensitive, both Email and Password start by a capital letter, whereas source and service are lowercase.
- About the -d modifier, indicates the name and value of an <input> element in a HTML form. If you want to learn more about how to compose HTTP frames with cURL check the following article: “The Art of HTTP Scripting”.
Once we got a valid Auth token, we can start using the service. All Google services work in a similar way. In general, we can perform any CRUD (Create-Read-Update-Delete) operation over them, in a Restful style, thanks to the most common HTTP methods: GET (for reading), POST (for creating), PUT (for updating) and DELETE (for erasing).
Let’s request a list of albums from my Picasa Web Albums account.
curl --silent -X GET http://picasaweb.google.com/data/feed/api/user/pinowsky?kind=album | tidy -xml -indent -quiet
Usually for reading operations there is no need to authenticate in before-hand neither providing any Auth token in the HTTP frame.
On the contrary, managing operations such as creating new data, deleting or updating, need an Auth token. Let's compose an HTTP frame using the Auth token retrieved in the first step. This operation will create a new album, together with its description, in my Picasa account.
curl --silent -X POST --data "@album_entry.xml" --header "Content-Type: application/atom+xml" --header "Authorization: GoogleLogin auth=DQAAAIAAAACQCCOvLjNU4y6zYclO4t75sjAWtWxx3C6OdYbMz3WXjn6rux_Jb3O25xzy5RCktrwH4oB2rKe3SsPq81ee2Pnv2VkPO_XrKYeuIP4dIqyuCsrlg1c4bZ4f5zTXD6GcMSTYfpts8KwR4m4Bn1x5siTq7ERpgXxqrOvZameELOhFEw" "http://picasaweb.google.com/data/feed/api/user/pinowsky" | tidy -xml -indent -quiet
where album_entry.xml is a file containing an album description in GData file format (as for the XML format of entries, GData is strongly based in Atom plus a customized set of tags added by Google). Check the Picasa Web Album Data API documentation for further information.
<entry xmlns='http://www.w3.org/2005/Atom'
xmlns:media='http://search.yahoo.com/mrss/'
xmlns:gphoto='http://schemas.google.com/photos/2007'>
<title type='text'>A day at the opera</title>
<summary type='text'>Funny pictures taking on the Faemino and Cansado show last December.</summary>
<gphoto:location>Vigo</gphoto:location>
<gphoto:access>public</gphoto:access>
<gphoto:commentingEnabled>true</gphoto:commentingEnabled>
<gphoto:timestamp>1361289600000</gphoto:timestamp>
<media:group>
<media:keywords>theater, show, humour</media:keywords>
</media:group>
<category scheme='http://schemas.google.com/g/2005#kind'
term='http://schemas.google.com/photos/2007#album'></category>
</entry>
Lastly, let’s delete the album entry we just created.
curl -s -X DELETE --header "Authorization: GoogleLogin auth=DQAAAIAAAACQCCOvLjNU4y6zYclO4t75sjAWtWxx3C6OdYbMz3WXjn6rux_Jb3O25xzy5RCktrwH4oB2rKe3SsPq81ee2Pnv2VkPO_XrKYeuIP4dIqyuCsrlg1c4bZ4f5zTXD6GcMSTYfpts8KwR4m4Bn1x5siTq7ERpgXxqrOvZameELOhFEw" "http://picasaweb.google.com/data/entry/api/user/pinowsky/albumid/5234863202168634657"
where 5234863202168634657 stands for the albumid.
In a nutshell, Google provides a Data API for many of their services. It is possible to use most Google services in a programmatic way. Before using any service, it is necessary to authenticate against it. If we were success, this authentication process will provide an Auth token as a result. This token would be needed later on for interacting with the Google service we just authenticate against. It is important to notice, there are two valid methods for retrieving an Auth token: AuthSub and ClientLogin. As a rule of thumb, use AuthSub for web applications, and ClientLogin for standalone applications. Remember, whenever interacting with a service, especially when creating new data, modifying it, etc it is necessary to embed a valid Auth token as a header in the HTTP frame. The Auth token must be present for every interaction. Auth tokens cannot be shared among different services, every service requires its own valid Auth token.
The AuthSub authenticating process is fully described in the following link: “AuthSub Authentication fow Web Applications” , whereas more detailed information about ClientLogin can be found here: “Authentication for Installed Applications”.
Permalink
« Previous entries
