Responsive Web Design.

Lately, I’ve been working on some responsive layouts. My task on these projects is to make a fixed-width layout into a responsive one. I’ve found it to be an engaging process.

Responsive web design is one of the “modern” big ideas of web development. It is becoming increasingly popular, and there is no sign of it going away anytime soon. The reason, I believe, is that responsive web design is just what we need on this era of small devices and huge screens. There has been an increased usage of big screens in the last few years. Whereas a few years ago 1024 was almost a standard, and we were all designing for those screens, nowadays people seem to have a tendency for much wider screens. Most laptops today come with at least 1200px resolutions, and people who work with desktop machines usually prefer even greater resolutions.

Along with this tendency for higher screen resolutions however, there is also an ever increasing usage of a wide variety of devices, each with different screen resolution, and many of them with portrait and landscape modes. This has presented a new challenge for designers and developers. Whereas in the past we could easily decide for 1024 and leave out a few old timers with 600px resolutions, now we cannot do that anymore. If we continue on that path, we are leaving out the increasing amount of people who browse the web on mobile devices daily.

The question then became: How do we deal with this new challenge? The answer is responsive layouts. Responsive layouts started earlier than we realize. They have their origins on the old, and never popular liquid layouts. Liquid layouts was the first step we took on dealing with the problem of different screen resolutions. However, they were never really popular because they presented a few challenges that, although not impossible to overcome, made fluid layouts more of a hassle tan static (fixes-width) ones. I think one of the reasons for this preference for static layouts is that web designers are mostly not real web designers, but graphic designers that saw an opportunity to make a few, and sometimes more than a few extra bucks. Graphic designers have some kind of obsession with pixel perfection. In itself that is not a bad thing at all, but when you bring that idea to the web, really bad things can happen. One of those things is that we are much too used to pixel units that we have almost forgotten how to work with percentages, and ems. This is a problem because those units are the building blocks of responsive web layouts.

I know I’ve been a bit aggressive towards graphic designers. Maybe I just envy their ability to create beautiful things out of a white canvas, but I prefer to think that my reasons are legitimate rather than selfish. I know that if you know and love web as much as I do, you will agree with me. Back to our topic of concern, how is responsive web design different from liquid layouts?

Responsive web design has been made possible thanks to new CSS3 features. Specifically media queries. Media queries are something somehow old and new at the same time. CSS2 offered the possibility to set different stylesheets for different mediums like screen, print, and screen readers, but CSS3 offers the awesome possibility of detecting the width, max-width, orientation (landscpape or portrait), and device width. This offers web designers/developers the chance of applying different styles depending on the width of the device, or the screen, or even the orientation. A two column layout can be easily converted into a single column layout when the size of the screen makes the columns too narrow to look beautiful or to be even readable. That is just awesome.

No longer do we need to have two or more versions of a single site to serve different devices. As programmers (I like to believe the web is build buy programmers, please let me continue deceiving myself), most of us are lazy. Moreover, we really hate doing the same thing twice. That is why we build libraries, and frameworks that simplify our work. I don’t think there is anything good, or fun about having to maintain two or more versions of the same site.

There is also another problem associated with these multiple-site approach. Often some sniffing techniques are used to decided which version to serve. I really have no idea of what they sniff for, but my guess is they check browser, and/or OS. This is a problem because sometimes you end up serving mobile versions of a site to devices that are fully capable of handling desktop versions of such site. For example, I have an Asus transformer tablet with 1200px(?) screen resolution, but sometimes I’m served little layouts that waste most my screen. One could argue that is still a good idea to serve such version to a mobile device given the cost of mobile internet, and the capabilities of it, but my tablet can connect to the internet only via wifi, so there is no real reason to do such thing. I would love to have the developers of those sites in front of me and tell them to stop sniffing and to start looking at the capabilities of my device, or at the very least give me an option to use the full site, not a semi functional version of it. This is why responsive layouts arise a champion on this matter.

Responsive layouts do not assume anything, but rather they set a few rules that apply or not depending on the device and window size. Moreover, responsive designs has a mobile first philosophy, which I see as the layout version of progressive enhancement. Mobile first is a great idea because it forces the designer into thinking about what is really important on each page. Mobile first lets us consider the content in a more responsible way, and to realize what is important, and what is not.

There is much more to talk about on this matter, and not everything is perfect. There are some parts of responsive web design that are not necessarily good, but overall, responsive web design is definitely one of the great ideas of web design that the modern world has come up with.

IF you wish to read more on this matter, I recommend the following articles:

Some of them are not necessarily about responsive web design, but about some of the things that make responsive web design possible, like fluid images.

Would You Please Learn How to Design Websites

I’d like to start by saying that I am not, nor do I pretend to be a graphic designer. I don’t do beautiful illustrations, logos, or graphics. I am not in the business of creating nice business cards, or great corporate identities. I do web.

I see a lot of graphic designers who develop wordpress themes, and other kinds of web related designs. I want to concentrate on wordpress themes, because that is what I’ve been dealing with lately. It really makes me tired, bored, sick, and it frustrates me when some guy who has been doing graphic design all his life comes to me and tells me: “The sidebar looks 2 pixels to the left on IE6.” The web is like that; dealt with it.

The beautiful web is more and more populated with sites that use too much resources. Websites nowadays load a stylesheet for modern browsers; one for IE7; another for IE6; another for hand-held devices; and tons of javascript to force their own font and to add shadows to sucky IE version. Seriously, that is not the way to do web.

I blame the guys who like everything with tons of eye candy. Those people who think it is really cool to have a stupid menu flying around are the ones destroying the precious web. What ever happened to sites that just worked? That were beautiful, functional, user friendly, and resources friendly. I admit it, it is pretty cool to have webGL, CSS animations, canvas coolness, and other tons of nice features, but you don’t have to use them all at once. Those tools should be only that: tools, but instead, they’ve become the website itself.

The root of the problem, I believe, is graphic designers, and graphic designer wannabies that once learned about jQuery, or some other of those toys. They thought, “look, I can make a big poster that moves!” I would like to salute them all with a huge facepalm.

When real web designers design, magic happens. We think in elements, not just colors and lines. Real web designers have a pretty good idea, not only of what is possible, and what is not, but of the amount of work and resources that something would take. We don’t think about an animation in terms of $(‘#elem’).animate(), but in terms of timeouts, loops, calculations, site repaints, usability, and accessibility. How does this animation help the user? How does it not help? What happens if the user is blind? What happens if the user has some kind of body movement difficulties? What happens if the user has and old computer? What happens if the user is using an old device/software? What happens if the user’s computer is doing some sort of heavy computation? At what point do we stop this animation and fall back to a more resources friendly version of the site? There is much to consider to have time to worry about 2 pixels on the sidebar.

Real web designers know their site won’t look the same everywhere. This shadow won’t come out on IE6, but that is OK, because I’ve designed the site in such a way that even without the shadow the site looks beautiful, and more importantly it works. Real web designers know that it is more important to save an http request and a few KB than to force that shadow to appear on IE6. The website will not look the same everywhere, and real web designers know that. This is what allows them to designs websites that look beautiful everywhere, even if they don’t look the same. We build for the user.

You are more likely to receive a complaint saying “Your website takes ages to load,” than one that says “on firefox the sidebar looks 2px to the right.” Please, learn how to design websites.

A Little About the setup_postdata() WordPress Function

Today I spent some minutes trying to get setup_postdata() to work. The problem I was having was that the function seemed to be setting the data for one post only. I was using it along with get_posts. If you look at the setup_postdata function documentation, you will find that it is really of not much help when it comes to finding out why it might not be working properly.

This is the situation I found myself in: I was developing a widget that takes the latest posts from the specified category and displays them. That is pretty easy to do. However, I hit an error when I was displaying the posts. The code looked like this:

function widget($args, $instance){
  //..some standard code
  $posts = get_posts($options);
  foreach($posts as $post){
    //..some more code here
  //..some more code here

I’ve got rid of the code that is not relevant to the situation.

That seemed to not work properly, and I got this output:


When I should have been getting this:


I went and checked the documentation of the functions involved and nothing seemed to be wrong. So I decided to look at the code of the function. I knew that the loop was setting the proper value for $post on each round. But for some reason setup_postdata was setting up the data for the same post over and over again.

It turns out I don’t really need to setup_postdata() at all, but I do it just to be sure. The functions I’m using to display the information are the_permalink, and the_title.

setup_postdata doesn’t really set up all the data related to a post. It sets only some of it, specifically the numeric ID, the author data, the day, the month, the current page, the content, whether the post is multi-page, the number of pages, and variable named $more that I currently am not sure what it is used for. This information is used by some functions like the_content.

The source of the problem was not really on setup_postdata, but on the_title and the_permalink. the_title, for example, relies on a function called get_the_title, which takes a single argument: a post id. This post id can be 0, which in fact is the default value. get_the_title then calls get_post, and passes the post id as parameter to that function. get_post, in turn, checks for that post id, if it is an empty value (zero is an empty value), then it uses the global $post, and that is where the problem was.

In order for functions like the_title to work properly when inside a function, you must declare a global post variable:

global $post;

you should do that, preferably at the top of your function. This overwrites the current global $post with the post that you are trying to access information from.

So, as it turns out, setup_postdata is a function that only sets some global variables that can be used by other functions like the_content. Keep in mind that you don’t always have to use setup_postdata, and if you do use it, always consider running wp_reset_postdata(); when you are done.

And finally, remember that functions like the_title, the_permalink, the_content, and so on, rely on the global $post. This means that you should always declare a global $post inside any function that uses those functions mentioned earlier. When looping through a set of posts that you got from functions like get_posts, always name the current item $post:

foreach($posts as $post)//<-That $post is important! Do not use another name, or it won't work.

I Love My Work, but I Hate Web Development

The more I work on web development, the more I realise how much I hate it. This is a very strange situation, especially because I do really love my work; I just hate the way I have to do it.

Let me explain what I mean. I hope that by the end of this long read you get the idea that I’m setting to communicate here, and that you join me on my rebellion against web development as it is today.

I will start with an example. Imagine a world where there are no computers, or typewriters, or even paper. All you have is rock and hard tools to scribe your thoughts. In this world there is a very high demand for books, which are made out of stone and cannot be mass-produced easily. You are a fiction writer. People love your books, and you love writing them. Except, that you hate having to write them.

It is not the idea of creating content that you hate, or the motion of writing itself, but rather the fact that it takes you a very long time to put those books on stone because of the rudimentary tools that you have. This is precisely what I mean in the title.

It is not the idea of creating an awesome website or webapp that I hate, but rather the nuisance that it represents actually creating them with the set of rudimentary technology that we have available. Even more annoying is the fact that not only do we have to use a very basic set of tools, but we also need to support even more archaic tools. And to add insult to injury, we are supposed to obey by a set of rules that have been laid out by people who mostly do not understand the web of today. Let along that one of tomorrow, which we should have gotten yesterday.

The more I work on web, the more I realise how wrong it feels to do it. It really feels wrong to have to create my content using a limited set of tags that were thought of by people who knew nothing about what I’m trying to create, and who would probably never care. It feels wrong to have to use an API that is mostly redundant (DOM), and designed by people whose work is not to create with this API. It feels wrong to have to do the same thing more than once to make sure that it works across browsers and platforms. I’m sure that by now you are getting the idea.

This is why Ajax libraries have succeeded. Ajax libraries are created, maintained, pushed, shaped, and refined by content creators, not by specification-and-standards writers. The people behind jQuery, Dojo, MooTools, YUI, and many others, are people who have created these tools to solve problems they have encountered in their journey as web and application developers. We need more of this, and less of W3C nonsense.

I used to be standards oriented until I discovered that the people behind the standards have no idea of what they are doing. Don’t get me wrong here. I have a lot of respect for the people who set out to standardise a huge mess such as the web. It is just that they have spent too much time trying that they haven’t realised the web changed.

The best time machine mankind has invented is called webstandards. While reading some of them, and not only web standards, one can feel like it’s re-living 2000 all over again. And it’s scary because sometimes you are actually reading a year-2000 document. This is insane. You cannot standardise the web of today when your base for standards is the web of 2000.

There are many examples of things that should have been done differently. One of the most common case-scenarios that frustrates me is CSS. In my opinion, and I express it because this is a very subjective essay, CSS is wrong. It starts with classes, then it degrades with some aspects of selectors, especially how they are interpreted, and it hits the bottom with the syntax passing for some other stages in the process.

The idea of classes is a language that has no way of extending this classes is wrong. One can argue that you can extend a class by adding the class name that you want to extend to the CSS declaration of the object from which you want to extend, like this:

color: blue;
width: 200px;
height: 50px;

If we want to create a new element that has the class name of truck, and we want it to extend the CSS of car, we can do it like this:

.car, .truck{
color: blue;
width: 200px;
height: 50px;
width: 300px;

This is fairly simple, but not quite usable when working on real projects because most of the time, by the moment you reach truck, you already added a hundred lines under the .car declaration. You have two options. One is to move your .truck declaration 100 lines up and mess up your CSS file organisation. The other is to leave them both 100 lines apart from each other which is also not good because the it becomes a maintenance problem, which by the way the first option does too.

Moreover, this is not extending, it is merely subscribing two classes to the same set of rules. Subscriptions are good, but not as the base for extending classes.

How I think it should be done:

color: blue;
width: 200px;
height: 50px;
/*100 lines of code go here.*/
.truck extends .car{
width: 300px;

What is the big difference? you might ask. This option also has the problem of having both declarations 100 lines apart from each other. However, in this version, there is a clear way to know that the styles that you see for .truck are not the only ones affecting .truck, where as in the current way of doing so, there in no such visual cue.

The whole idea of classes is wrong in most programming languages, but that is material for a whole other essay.

There are many ideas that have been laid out to solve the many issues of CSS, two that come to mind are OOCSS, and Stylus. Both are worth a look.

CSS is not a programming language. Rather, it is a styling language, which was good enough for when the web was a bunch of static documents. It even made sense when the webapps where things like forums, blogs, and e-papers. Today we need a styling language that borrows ideas from programming languages. One feature that would be a first good step in the right direction is adding variables to the language, and arithmetic capabilities. Stylus implements these ideas.

CSS is a styling language, but we need it to become a state representation language. The web of today is state based, and CSS doesn’t do well in this area. Moreover, we need it to be an animation language. So far Javascript has done that job, but CSS has demonstrated that it has potential to do it to.

Another reason why I hate web development is HTML. There is a lot of excitement about HTML5, which is good, but there are fundamental flaws in the design of HTML that just make the language not suitable for the web. There are, for example, security issues with window. This could be thought of as a problem with javascript, but it is not. Javascript has no window, that is an HTML global variable. Javascript has a global object, and window refers back to that global object, but window is not part of Javascript, it is the global object implementation in HTML. HTML5 does nothing to solve this issue. Instead, it adds more complexity to a system that is in itself complex, and complexity is the first enemy of security. But there are more fundamental problems with HTML.

HTML is a very closed language. HTML has a defined set of tags. This tags have a define behaviour, and you cannot expand this tags. Technically you can, but at some point you will run into trouble. There is no way to create semantically meaningful markup with the language that we have today. This can be argued, of course, but the truth is that HTML is too small to cover the needs of developers today. In order to create meaningful markup you need to use classes, and IDs, and this becomes a problem when you are creating webapps.

Once I said that HTML5 was built for blogs. The new additions to HTML that conform the HTML5 specification has a clear influence from the blogging community. They wanted an article tag, an aside tag, a section tag, a header tag, a footer tag and all of the rest because that is what they need. If you get together with blog designers, all they talk about is content, footer, sidebars and sections. We cannot build the web on top of blogging engines.

We need a language that allows us to specify more than just content sections; we need to be able to specify UI elements other than input boxes and buttons. There are some new elements that allows us to do this, like some new form elements that promise a brighter future, but it is not enough. We should have gotten those back when the talks about web 2.0 were all over the web.

HTML is just not suited for web development today.

It seems that from the stack (HTML, CSS, and Javascript), the only language being pushed in the right direction is Javascript (actually Ecmascript). This is a good thing.

Finally, the DOM is a mess. When people say the hate Javascript, the usually mean this:

var a = document.getElementById(‘myID’);
var b = document.createElement(‘span’);
b.appendChild(document.createTextNode(‘My text’);

I look at them and say, please step back from the computer and read a book. That is not Javascript. What you are seeing right there, that mess is the DOM’s API.

The DOM has many design issues that are beyond my willingness to explain them. The one thing you should know about it is that it was poorly design and it’s an awful thing with which to work. It is ridiculously repetitive and has horrible method names. Don’t let people fool you into thinking that is the way to write methods, because it is not.

There are many other reasons to hate web development, like the one we call IE*, but I think you get the idea.

There are two things that need to happen for web development to really advance. The first is we need to rethink HTML and CSS, and the second is getting rid of browsers that are holding back web development. Until this happens, we will be living in a world with a wasted web.

*IE is getting better, but that is of no use when the older version stick around for too long like they do.

Seguridad en Javascript Parte 2

Hace algunos días hablamos sobre seguridad en javascript con ejemplo de XSS. Hoy ha llegado el momento de retomar la platica y empezar a analizar algunos otros aspectos de seguridad en javascript. Vamos a continuar con nuestro ejemplo y los chicos de

Supongamos que ha notado su error, (estos chicos visitan este blog seguido) entonces han decidio hacer algo al respecto. Comienzan a buscar en google y se dan cuenta que una forma más efectiva de hacer el truqillo del saludo personalizado es almacenando el nombre del visitante en una cookie. Esta mejora tiene la ventaja de qe la cookie se puede guardar en el cliente por lo que el saludo personalizado duraría más que una sesión. No vamos a discutir el código para el almacenamiento de la cookie, ya que nuestro objetivo con esta serie de artículos es simplemente resaltar algunas de las fallas de seguridad que se pueden encontrar los desarrolladores javascript.

El problema con almacenar el nombre en una cookie, es que las cookies son fácilmente editadas. En la actualidad no es necesario siquiera saber en donde se almacenan las cookies ya que con el simple hecho de usar firefox y una extensión como web developer tools puedes editar las cookies, ya que esta extensión te ofrece la posibilidad de hacerlo directamente desde el navegador.

Igual que con el ejemplo de XSS, se puede inyectar código en la cookie de modo que sea ejecutado. Nuevamente recordamos que todo dato que no sea generado estrictamente por la aplicación debe ser validado sin importar su procedencia.

Esta técnica de ataque es especialmente útil en sitios públicos como café internet, librerías, escuelas y otros lugares donde se permita el acceso a internet a diferentes usuarios desde la misma máquina.

Las cookies no son el único sistema de almacenamiento del lado del cliente que puede ser contaminado con la intención de atacar un sitio o un usuario. Otros sistemas de almacenamiento como los ofrecidos por firefox o google gears pueden de igual forma ser contaminados. Por tal razón, no está de más repetir la recomendación: Chequea cada pieza de información que entre a tu aplicación sin importar su procedencia.

Veamos un ejemplo del tipo de daño que puede causarse con este ataque.

Supongamos que usuario A visita la página de su banco en un sitio público. Su banco almacena cookies en el navegador para después recuperar la información almacenada en ellas y ponerla en la pantalla. Probablemente parte de esa información es la última fecha de visita. Entonces cuando usuario A vuelve a entrar a la página del banco, la página lee la cookie almacenada, toma su valor y muestra un mensaje que dice “tu última visita fue: febrero 1 de 2010″. Ahora, usuario B ha notado que el banco falla en hacer un chequeo del dato recuperado por la cookie, por lo que espera a que usuario A desocupe la máquina y la toma para su uso, o mejor dicho, su abuso.

Usuario B va a las cookies y busca la que guarda la información de la última fecha de uso. Cuando la encuentra la edita agregando lo siguiente:

<script type=”text/javascript” src=””></script&gt;

Como solo puedes guardar cierta información en una cookie, usuario B prefiere simplemente usar un tag script que llama a un archivo desde un servidor remoto. Este archivo es el que hará todo el trabajo sucio.

A partir de aquí todo es sencillo para usuario B ya que basta con un document.write() en el archivo llamado desde el servidor remoto para insertar código ajax el cual haga cosas como transferir dinero de la cuenta de usuario A a la de usuario B. No habrá forma de que usuario A reclame por esas transacciones ya que lo que pasará es lo siguiente:

Usuario B solo ha estado unos minutos en la computadora que usuario A uso para chequear su cuenta bancaria. Para no parecer sospechoso, permanece un poco más de tiempo haciendo cosas comunes como chequear su correo, ver un par de videos y luego, cuando calcula que ya ha estado suficiente tiempo para no levantar sospechas, se va. Al día siguiente usuario A vuelve para chequear su cuenta bancaria (Esta esperando confirmación de un pago o algo por el estilo). Ingresa en su cuenta y su banco busca la cookie que le dice cuando fue la última vez que uso el sitio. Lee la cookie y con ella el código para el ataque. El banco ha registrado que usuario A esta loggeado y todo el traspaso de fondos pasa mientras que usuario A está loggeado, por lo que desde el punto de vista del banco, usuario A ha hecho todos los movimientos que en realidad han sido hechos por un script.

Cuando usuario A deja el sitio, su banco vuelve a registrar esta fecha como la última fecha en que usuario A visitó el sitio, reescribiendo así la cookie anterior y borrando todo rastro del ataque hecho por usuario B.

Al final del día usuario B ha ganado todo el dinero de usuario A, usuario A se ha quedado sin dinero en el banco, y el banco no puede tomar una queja por que todo ha ocurrido mientras usuario A estaba loggeado. Para usuario A será muy difícil demostrar que no fue él quien hizo los movimientos ya que como la cookie fue reemplazada, no hay rastro de la contaminación hecha por usuario B.

Ahora, hay muchos factores que tiene que estar en sincronía para que algo como esto pueda pasar. Sin embargo, la intención es solo demostrar el tipo de ataques que se pueden lograr con tan solo contaminar la información en una cookie cuando el sitio que recibe dicha información no realiza un chequeo para asegurar que no haya nada malicioso en ella. También, a través de este ejemplo demostramos que por seguridad se debe guardar la menor cantidad de información posible del lado del cliente, donde es accesible y vulnerable. Un No No, es guardar información confidencial como nombres de usuario y contraseñas.

Verificar los datos que recibimos por parte del usuario, del cliente o de otros servicios (hablaremos de esto en el futuro) no hará nuestras aplicaciones 100% seguras, pero si nos protegerá contra la mayoría de los ataques comunes en la web.

javascript seguro. -parte 1

En diciembre del año pasado decidí dejar de trabajar en mi antiguo empleo para convertirme en freelance. Debo decir que la verdad ha sido un poco difícil ya que aun que tengo la experiencia que muchos que agarran trabajos no tienen, me hace falta el portafolio que respalde esa experiencia. Sin embargo, no me puedo quejar; he obtenido algunos proyectos que me han permitido salir adelante y en el camino he ganado a más de un amigo. Una de las cosas que no me faltan cuando envío un presupuesto, es mencionar que soy un desarrollador enfocado en optimización y seguridad por lo que he decidido escribir un poco sobre seguridad aquí en el blog.

Para empezar con esta serie de artículos voy a tratar uno de los temas más comunes en el ataque a la seguridad, o falta de esta, de un sitio. Para ello voy a usar un ejemplo. Supongamos que el sitio ha sido desarrollado por unos chicos que se han creído que por saber unas cuantas etiquetas de html y como encontrar trucos cool de javascript en la web ya son programadores web. Como estos chicos quieren demostrar sus habilidades de programadores han puesto un toque ‘personal’ a su sitio de modo que cuando ingresas a te sale una ventana pidiendo que introduzcas tu nombre. Tu introduces tu nombre y le das a aceptar. El sitio entonces, ‘se aprende’ tu nombre y cada que cambias de pagina en la cabecera te aparece un mensajito que dice ‘Gracias por visitar el sitio nombre‘, donde nombre es tu nombre. Para hacer esto, nuestros amigos se valen de técnicas poco seguras. Para pasar el nombre de una página a otra usan el variables que pasan por get, las cuales después toman en la siguiente página para poder imprimirlas en la cabecera del sitio. Cada enlace se ve de esta forma:

Por supuesto que esto llama nuestra atención desde un inicio y empezamos a especular sobre lo que podría pasar si le movemos por aquí y por aya. Lo primero que hacemos es modificar el valor de nombre y ver que pasa.

Accedemos a esa dirección diréctamente y vemos que efectivamente en lugar de imprimirse mrB como nuestro nombre, se imprime srB. Ahora empezamos a probar un poco más y volvemos a editar la url.<script>alert(‘XSS&#8217;);</script>

Navegamos hacia esa dirección y Oh YES!!!, obtenemos una alerta que dice XSS. Pero, que fue lo que pasó?

Para ver un poco el fallo de nuestros amigos veamos un poco como es que este sitio hipotético ha sido montado.

Primero, al cargar la primera página nos sale un prompt, desde el cual, por cierto, podemos hacer el ataque. Este prompt nos pregunta por nuestro nombre para después poder almacenarlo en una variable y agregarlo a cada enlace. Cuando navegamos a otra página dentro de, esa otra página recoge la variable nombre de url y la inyecta en el html tal como viene. Para eso pueden usar un simple document.write

var obtNombre = function(){
//code para obtener el nombre de la url
return nombre;


Como puedes ver, el código empleado simplemente recoge la variable nombre de la url, lo cual puede hacerse de diferentes maneras, y lo inserta tal como viene en el documento. Aquí es donde podemos ver el gran error de los chicos. Como no hay nada que valide o que haga un chequeo del dato que se está recibiendo, podemos simplemente pasar cualquier cosa y el código la va a inyectar en la página, es por eso que nuestro alert() funciona ya que al ser inyectado, es interpretado como otra pieza de código más.

Ahora, cual es realmente el problema, preguntarán algunos. Que daño puede hacer una alerta? La verdad es que no mucho. Sin embargo, el problema radica en el hecho de que existe la posibilidad de inyectar código dentro de la página. Algo que muchas veces pensamos es, por que quería yo modificar una url para inyectar code en un sitio que estoy visitando? La verdad es que no se por que querrías hacer eso. Lo que sí se, es que no es lo que chico que sombrero negro haría. Nuestro amigo (de verdad???) de sombrero negro haría es por ejemplo mandar un email en el que de una u otra forma intentara convencerte que visitaras el sitio El enlace por supuesto que ha sido modificado de modo que inyecte código dentro del sitio para atacar a la persona que está visitando el sitio, es decir, la persona que recibió el mail y que siguió el enlace. El código inyectado puede hacer infinidad de cosas dependiendo el sitio que está siendo usado para hacer el ataque.

Imagina que en lugar de ser el sitio que tiene la vulnerabilidad, es Entonces el panorama se torna completamente diferente ya que en el atacante puede hacer mucho daño. Otro caso puede ser que tu servicio de correo fuera el vulnerable, entonces el atacante podría robar desde tu correo hasta tus cookies para poder después entrar al sitio como si fueras tu.

A este tipo de ataque se le conoce como Corss Site Scripting, y dejar vulnerabilidades abiertas para este tipo de ataques es muy fácil, especialmente si no se sabe lo que se hace al desarrollar un sitio web. Los medios más comunes para este tipo de ataque son campos de texto o áreas de texto ya que muchas veces esto sirven para postear mensajes o comentarios. Si la información introducida por el usuario nos propiamente chequeada y validada, lo más probable es que se sea víctima de este tipo de ataques. Por ejemplo, alguien puede dejar un comentario como este:

Hola, está bueno el artículo. <script>//algo de js malicioso…</script>

Ese comentario se guarda en una base de datos y cuando alguien más visita la página, se cargan los comentarios y entre ellos el comentario que lleva el ataque. De esta manera, nuestro amigo de sombrero negro ha logrado atacar a alguien más.

En un futuro artículo estaré hablando más sobre ataques y como defenderse de ellos. Por ahora los dejo con la regla de oro en seguridad: Todo contenido provisto por el usuario debe ser propiamente chequeado y validado. Como dicen en inglés, trust the user, but not the input.

Validando fechas de forma sencilla en Javascript.

Siendo sincero es muy rara la vez que tengo que trabajar con fechas en Javascript, pero hoy me encontré con la necesidad de validar un campo fecha y decidí hacerlo de la siguiente manera. Aclaro que este validador es muy sencillo. De hecho es extremadamente sencillo, pero efectivo. No he visto en todo el tiempo que he trabajado con javascript una función para validar fechas tan sencilla. Si alguien encuentra un defecto en ella, les agradecería el feedback.

var validarFecha = function(fecha){
 //Funcion validarFecha 
 //Escrita por Buzu feb 18 2010. (FELIZ CUMPLE BUZU!!!
 //valida fecha en formato aaaa-mm-dd
 var fechaArr = fecha.split('-');
 var aho = fechaArr[0];
 var mes = fechaArr[1];
 var dia = fechaArr[2];
 var plantilla = new Date(aho, mes - 1, dia);//mes empieza de cero Enero = 0

 if(!plantilla || plantilla.getFullYear() == aho && plantilla.getMonth() == mes -1 && plantilla.getDate() == dia){
 return true;
 return false;

Como puedes ver hace uso de Date evitando así esos códigos para checar si el año es bisiesto o no y evitar checar que los meses tengan la cantidad de días correcta. El uso de Date de forma inteligente es la clave en esta función.

Espero que les pueda ser útil.

Para los que preguntan cuanto cobrar por una web.

Una de esas preguntas recurrentes en los foros es cuanto cobrar por una web. Casualmente me llegó a las manos un presupuesto que le había hecho una compañía a mi cliente más reciente. Les dejo los datos que tiene el presupuesto para que se puedan enterar más sobre cuanto cobrar. Quiero dejar en claro que estos para nada son mis precios, los cuales en realidad yo calculo individualmente por proyecto. Tampoco pregunten si yo cobro más o menos por que eso está fuera del panorama. Lo único que si les puedo decir es que en un país como Mx, de donde viene el presupuesto, los precios me parecen razonables, aun que el servicio se me hace un poco precario. No revelo la identidad de la compañía que tiene estos paquetes por dos razones, 1) no hacerles promoción, 2) no creo que fuera correcto hacerlo.

Web Profesional.

Indicada para pequeñas empresas que simplemente desean tener su tarjeta de visita en internet.
Consiste en realizar de forma atractiva una presentación eficaz de su empresa, de modo que la
pagina sirva de toma de contacto para sus clientes y proveedores por internet. En ella se es la
opción mas usada por despachos de consultoria, que desean tener una presencia en internet junto
con sus direcciones de correo personalizada para reforzar su imagen ante sus clientes. Se puede
contratar desde $4,950 m.n. y su precio variara según la complejidad final de dicha pagina y de las
ampliaciones que tenga su estructura

Incluye registro de dominio y
hospedaje durante el primer año.

Desarrollo web html.

•   Pagina de información sobre
la empresa (historia, casos

de éxito, etc.)
•   Fotografías de productos.
• Conceptualizar atraves de

imágenes sus servicios.
•   Pagina para envio de correo
electrónico sin necesidad de

•   1 a 5 cuentas de correo
electrónico de alta

•   Pagina principal con
producto destacado, noticias

de la empresa y una breve
introducción a ella.

$4,950 + IVA

Mantenimiento de la pagina $100.00 c/mes a partir del segundo  año el

costo anual es de $1,200.00. nota: 40% para iniciar el trabajo, 30% al aceptar
la plantilla y 30% al terminar el trabajo.

Web PyMe.

Orientada a aquellas empresas que desean tener una presencia notoria y de calidad en internet.
Se trata de dar a sus clientes de forma practica y eficiente información sobre sus novedades,
productos, promociones, y referencias de modo que la pagina sirve de una toma de podríamos
decir que existen tres tipos principales de proyectos web; los basados en paginas HTML con
contenido estético ( impacto visual básico), los basados en paginas HTML donde:

Incluye registro de dominio y

hospedaje durante el primer año
desarrollo web HTML‐flash
Catalogo de productos.

Paginas para productos o

Baner para promoción de

productos o servicios.
Pagina de información

sobre la empresa (historia,
casos de éxito, etc).
Fotografías de productos

Conceptualizar atraves de

imágenes sus servicios.
1 a 10 cuentas de correo de

alta capacidad.
Pagina principal con

producto destacado,
noticias de la empresa y
una breve introducción a

Sitio animado para

incrementar permanencia
de visitas.

$7,950.00 + IVA

Mantenimiento de la pagina $150.00 c/mes a partir del segundo  año
el costo anual es de $1,200.00. nota: 40% para iniciar el trabajo, 30%
al aceptar la plantilla y 30% al terminar el trabajo.

Web Corporativa.

Ideal para aquellas empresas con una gama amplia de productos y servicios. Empresas
orientadas 100% al cliente, que deseen aumentar sus ventas y la publicidad de sus productos. En
este tipo de paginas web se muestra principalmente el listado de productos o servicios que se
quieren ofrecer, ordenados por precios y marcas con búsqueda por palabras.
1. Mostrar o vender productos de su empresa con detalle en fotografía y características.
2. Actualizar los productos o servicios desde una parte privada de la web de una forma fácil y
sencilla desde cualquier lugar, negocios o casa (siempre que haya una conexión a
3. Se podrán realizar compras a través de la web, realizar presupuestos y consultar las
características de los productos existentes de forma rápida y sencilla.

Incluye registro de dominio durante
3 años y hospedaje durante el primer año.

Desarrollo web HTML‐Flash  y FLASH.

•   Catalogo de productos.

• Paginas para productos o
• Baner de información sobre la
empresa (historia, casos de éxito,
• Fotografía de productos y/o
• Conceptualizar a través de
imágenes sus servicios.
• Pagina para envio de correo
directo sin necesidad de
• Configuración de tienda virtual
para procesar pedidos (no pagos
• Alta de productos o servicios de
la empresa en la tienda.
• 1 a 20 cuentas de correo
$9,950.00 + IVA
electrónico de alta capacidad.
• Pagina principal con producto
Mantenimiento de la pagina
destacado, noticias de la
$200.00 c/mes a partir del segundo
empresa y una breve
año el costo anual es de $1,700.00.
introducción a ella.
nota: 40% para iniciar el trabajo,
• Sitio animado para incrementar
30% al aceptar la plantilla y 30% al
permanencia de visitas.
terminar el trabajo.

Notas sobre z-index

Estoy escribiendo una galería y he descubierto algo interesante. El cliente requiere que la galería sea una especie de light box por lo que tengo que trabajar con elementos transparentes. Si alguna vez has trabajado con elementos transparentes sabrás que un div con transparencia del 70% forzará a todos los elementos que contiene a tener dicha transparencia aun cuando tu especifiques que esos elementos deben ser completamente opacos. Esto trae un problema: no se pueden poner más elementos dentro del elementos transparente, por lo que este sirve solo como una pantalla. Para poder posicionar elementos sobre él y que estos no sean transparentes es necesario que se coloquen en otro contenedor y que este contenedor se posicione sobre el elemento transparente. Esto realmente no representa un problema, pero me llevó a descubrir una curiosidad sobre z-index de la que no había oído antes.

Intentando diversas opciones, llegué a considerar poner el elemento transparente con posición fixed para evitar que se mueva cuando se hace scroll y así asegurar que la pantalla esta cubierta en todo tiempo. Después quise poner el elemento que quería mostrar sobre la pantalla con su posición por defecto para poder aprovechar algunas ventajas de esta posición. Pensé que con usar un z-index de 1000 sería suficiente pero no fue así. Resulta que un elemento cuya posición no ha sido modificada (usando position en CSS)  no puede posicionarse sobre un elemento cuya posición es fixed o absolute sin importar el z-index que se le asigne al elemento cuya posición no ha sido modificada. Esto puede resultar poco interesante para muchos, sin embargo, a mi me ha tomado por sorpresa por que son de las cosas que no te enseñan en los libros y que solo aprendes con la experiencia. Lo bueno de esto es que te ayuda a conocer más la forma de funcionar del lenguaje y esto te ayuda en desarrollos futuros. Saber como funciona el lenguaje y la web en general es muy importante como lo comprueba este post:

Está Vivo!- El impacto ajax.

Hace un par de días comencé a notar una cosa. Primero fue con twitter y su nueva funcionalidad (que al parecer por el momento la han deshabilitado) de actualizar el sitio cada vez que hay twitts nuevos. Me encantaba por que solo dejaba la ventana abierta y en cualquier momento el titulo de la pestaña cambiaba para indicar cuantos twitts nuevos había. Es mucho más fácil estar al tanto de twitter (y esclavizase a él) de esa manera sin tener que tener otra app abierta. Después comencé a notarlo con otros sitios. Por ejemplo, actualiza su barra lateral cada cierto tiempo. Llegó el momento que me dije a mi mismo, Gush! este sitio está vivo!. No es la primera vez que veo que un sitio se mueve por si solo. He visto cientos de rolling menus, y sitios que de una u otra forma “se mueven”, pero eso no me impresiona. Después de todo, todo eso que se mueve no es más que un loop, algo que alguien programó antes y que no cambia-un .gif programado. Sin embargo, estos sitios están no solo moviéndose, sino auto actualizándose para mostrarte el nuevo contenido y es eso precisamente lo que causa la sensación de WOW!

Como programador que soy, se que todo lo que hay detrás no es más que ajax, pero la verdad aun así me impresionó. Probablemente sea por que es una de las primeras veces que veo ajax empleado de forma usable, amigable y responsable, o quizá solo me agarró desprevenido y me sorprendió. Cualquiera que sea la razón, la verdad que por un momento me hizo sentir que estaba viendo algo vivo, algo que se movía, y me produjo la sensación que te produce ver cuando un recién nacido mueve una mano-simplemente increíble. Posiblemente esté exagerando, después de todo ajax ya está creciendo barba. Sin embargo, es agradable ver que finalmente los desarrolladores están aprendiendo a usarlo de forma benéfica y no solo para impresionar damiselas. Seguro que la web nos depara muchas sorpresas todavía. Apps como wave se abren paso y cada vez la web deja de ser ese papel lleno de formularios que proveen la única forma de interacción. En lo personal no me emociona las animaciones ni los drag and drop.  Eso lo veo más bien como simples trucos de feria. Los verdaderos avances en la materia son aquellos que no se notan, que han sido tan bien calculados, planeados y desarrollados que se introducen de forma natural de modo que el usuario nunca se da cuenta que lo está usando y por lo tanto nunca tiene que aprender algo nuevo ni adaptarse aun nuevo método de interacción. Way to go, pero la web es cada vez más excitante y nos exige a notros, lo programadores que de cierta manera somos participes en esa evolución web, cada vez mejores y más responsables metodologías para el uso y la aplicación de las nuevas tecnologías. Ahora solo tenemos dos caminos, sentarnos a esperar más avances en la materia, o se nosotros mismos quienes impulsemos eso avances. Tu cual escoges?