Burbujas en .NET - Todos los comentarios

re: Combos en ASP.NET MVC

Eduard Tomàs i Avellana — Wed, 08 May 2013 14:45:10 GMT

Buenas @sebastianherrera

ASP.NET MVC no soporta directamente el concepto de "combo múltiple para una sola tabla". Es decir, tu debes leer los datos de esa tabla y organizarla en dos combos: dos objectos SelectList que mandas hacia la vista.

Saludos!

re: Combos en ASP.NET MVC

sebastianherrera — Thu, 02 May 2013 15:52:15 GMT

Eduard, este caso muestra el ejemplo de dos tablas, una para estado y otra para city.

que cambiara en el caso de que sea un combo multiple para una sola tabla?. ejemplo tipico es la tabla categorias con multiples parent id.

ejemplo:

categoryid | nombre de categoria | parent_categoryid

existe forma de hacer un multiples combos en funcion de la cantidad de parent categories que tenga?

muchas gracias!

sebastian.

re: Como hacer seguros tus servicios WebApi

Eduard Tomàs i Avellana — Tue, 30 Apr 2013 20:11:50 GMT

Buenas!

Si, en el WebApiConfig que se llama tan solo desde del Application_Start (todas esas clases XXXConfig se llaman tan solo desde el Application_Start y son para "organizar" código).

Sobre lo del web.config, el primer parámetro es el nombre completo de la clase (namespace.clase) y el segundo es el ensamblado.

Un saludo!

PD: Si tus servicios WebApi son TAN SOLO para la aplicación web y están contenidos en la misma aplicación web, entonces puedes usar la propia seguridad de Forms para autenticar tus servicios web. Es decir, NO necesitas hacer nada especifico (ni HttpModule, ni Message Handler) ni nada. Si el usuario está autenticado en tu aplicación web, lo estará en tus servicios web (asegúrate tan solo de usar <authentication mode="Forms" /> en el web.config. Lo tendrás si has partido del template de "Internet Application" de MVC y NO lo tendrás si has partido del template de WebApi). Si es el caso puedes usar directamente [Authorize] para decorar los servicios web que requieren usuario autenticado (el [Authorize] de WebApi, no el de MVC).

Saludos!

re: Como hacer seguros tus servicios WebApi

Beni — Tue, 30 Apr 2013 16:27:04 GMT

Eduard:

Sí, me has aclarado bastante. El problema es que yo lo estaba viendo todo como un uno (el login propiamente dicho del sitio web MVC y la seguridad de los servicios web.api) y una cosa es un pantalla de login y otra las peticiones de datos a la API una vez que el usuario está "dentro" de la aplicación. En mi caso, que es MVC+Web.API con IIS, todo con HTTPS, tu ejemplo con HttpModule es perfecto.

Tan sólo dos comentarios:

- Cuando dices que el Message Handler hay que registrarlo en Application_Start, no sería en WebApiConfig?

- Y dos: no he conseguido hacer funcionar el ejemplo con HttpModule por el web.config.

<add name="BasicAuthHttpModule"

type="MvcSecureDemo.BasicAuthModule, MvcSecureDemo"/>

El primer parámetro en "type" entiendo es el ensamblado? Cuál es el segundo?

Muchas gracias de nuevo.

Saludos.

re: Como hacer seguros tus servicios WebApi

Eduard Tomàs i Avellana — Tue, 30 Apr 2013 08:11:35 GMT

@Beni

El problema de la autenticación básica es que login y password viajan sin encriptar por la red (en Base64). Eso lo hace totalmente inutilizable en escenarios donde NO haya https. Con https NO hay problema alguno en utilizar autenticación básica, ya que dado que el canal ya está encriptado, no necesitamos encriptar o hashear de nuevo la información.

Hay tres elementos que debemos diferenciar:

1. El canal usado (básicamente http o https)

2. El protocolo de autenticación que usemos (autenticación básica, digest, oauth, etc)

3. La implementación de dicho protocolo (filtro, httpmodule, message handler).

En este post me he centrado en el punto 3, es decir cuento COMO implementar técnicamente cualquier protoclo de autenticación. Las 3 opciones fundamentales (en webapi bajo IIS) son las 3 que menciono: filtro, httpmodule o message handler).

Por lo tanto puedes implementar autenticación básica con cualquiera de estos 3 mecanismos al igual que puedes implementar oauth con cualquiera de esos 3 mecanismos. Como digo en el post usar un filtro NO es buena idea ya que el filtro debe autorizar peticiones y no autenticarlas. Así que a la práctica nos quedan 2 opciones: message handlers o httpmodule. En un escenario con IIS un httpmodule es la mejor forma. En un escenario con self-hosted webapi no tenemos httpmodule así que nos toca tirar con message handlers. La ventaja de un httpmdoule versus un message handler es que el primero se ejecuta antes de todo el pipeline de webapi, así que puede autenticar también otras peticiones.

La plantilla de MVC como base (aplicación internet) utiliza el método de autenticación basado en forms, que es un método basado en cookies. Este método está bien para la web (los navegadores envían las cookies automáticamente) pero no para otros clientes que no entienden de cookies. Recuerda que [Authorize] NO autentica, autoriza que no es lo mismo. Si la petición NO está autenticada [Authorize] la deniega (si no estás ni autenticado es obvio que no puedo autorizarte a nada) pero [Authorize] no define como te autenticas (con cookie, con basic, con oauth?).

Los sistemas de token (como oauth que "describo" al final del post) tienen su uso, en dos escenarios:

1. Cuando NO hay canal seguro (es decir vamos bajo http) y no podemos transferir las credenciales (login/pwd) por la red.

2. Cuando, incluso teniendo canal seguro, NO confiamos en el cliente y no queremos que este tenga acceso a nuestras credenciales. Imagina que tu te instalas una aplicación de twitter en tu móvil. Si le das tus credenciales a la aplicación esta puede hacer lo que quiera, y tu a lo mejor (como usuario) no confías en esta aplicación o bien NO quieres otorgarle todos los permisos (p. ej. que solo pueda leer pero no publicar). Eso es posible con sistemas basados en tokens como oauth.

Sobre Thinktecture.IdentityModel lo conozco pero no lo he usado, así que poco te puedo decir :)

Espero haberte aclarado!!!

Saludos!

re: Como hacer seguros tus servicios WebApi

Beni — Mon, 29 Apr 2013 23:58:07 GMT

Eduard, enhorabuena por el blog. Es un gustazo leer este tipo de material y con este nivel tan alto en español.

Tengo unas preguntas: si usamos SSL para seguridad, entendido como el sistema más fiable, de qué depende el uso de uno u otro método de autenticación (básica, HTTP handlers, etc? Me refiero usando IIS, Microsoft en estado puro. Tu usas la plantilla de MVC como base para tu ejemplo, no sería suficiente con eso? Te digo esto porque hay tantos blogs con mil explicaciones con diferentes métodos que al final es demasiada información la que manejar, y entiendo que habrá razones para elegir uno u otro método, porque si no, se añade una complejidad innecesaria al proyecto.

Qué hay de los sistemas de token? Seguro que conoces Thinktecture.IdentityModel, qué opinión te merece?

Muchas gracias y sigue así, aquí tienes un nuevo seguidor!

re: Combos en ASP.NET MVC

Kiquenet — Fri, 26 Apr 2013 06:00:34 GMT

Fabuloso Eduard ! Saludos.

re: HTML5 - Que tus usuarios suban su foto a su perfil (WebRTC)

Romny — Fri, 19 Apr 2013 12:29:27 GMT

Muy buen post. Asi nos quitaríamos un dolor de cabeza en usar cosas de terceros.

re: HTML5 - Que tus usuarios suban su foto a su perfil (WebRTC)

Santiago Porras Rodríguez — Fri, 19 Apr 2013 08:44:37 GMT

Muy bueno oiga, muy bueno!

HTML5 - Que tus usuarios suban su foto a su perfil (WebRTC)

Burbujas en .NET — Fri, 19 Apr 2013 08:31:47 GMT

Venga, seguro que como la mitad de mortales tienes una idea de negocio que consiste en hacer una web

re: Objective-C para desarrolladores de C# (ii)–Punteros

Eduard Tomàs i Avellana — Tue, 16 Apr 2013 15:28:29 GMT

Buenas Juanma!

1) Pues sí. El uso de ARC es muy parecido, conceptualmente al concepto de smart pointers en C++. De hecho un shared_ptr proporciona un contador de referencias si no tengo mal entendido. La diferencia está en que ARC es como más "mágico": usas punteros normales y dejas que el compilador haga la magia. Hay tan solo algunas consideraciones que debes tener presente y en general funciona bastante bien.

2) En mi opinión ninguna. Yo la contaré porque me parece que es una buena ocasión de ver como funciona un contador de referencias manual. Pero, vamos, yo siempre uso ARC :)

Saludos y gracias por comentar!!!

re: Objective-C para desarrolladores de C# (ii)–Punteros

Juanma — Tue, 16 Apr 2013 13:44:36 GMT

Partiendo de que no tengo ni idea de Objective-C, y de que mis conocimientos sobre C/C++ están bastante oxidados, un par de dudas:

1) ¿La gestión de memoria con ARC sería equivalente al uso de smart pointers en C++ (auto_ptr, shared_ptr y compañía)?

2) ¿Qué ventajas tendría usar gestión de memoria manual? A simple vista parece que sólo son ganas de meterse en líos, a menos que tengas que reutilizar código escrito en C puro.

re: WebApi–Recibir en un controlador un IEnumerable desde URL

Julio Avellaneda — Wed, 06 Mar 2013 15:01:30 GMT

De verdad un gran post, y me sirvio para solucionar un caso casi igual al que comentas, lo escribiste a tiempo!!

Saludos!

re: WebApi–Devolver tipos anónimos en XML

Xavi Paper — Tue, 05 Mar 2013 03:19:01 GMT

Muy bueno Eduard, sencillo pero muy bueno...

re: ¿Están tus servicios REST en otro servidor?

Eduard Tomàs i Avellana — Mon, 04 Mar 2013 13:24:54 GMT

@MetalTux

En una API REST se usan los distintos verbos http para las distintas actualizaciones. Generalmente:

PUT -> Para insertar/modificar datos

POST -> Para insertar/modificar datos

DELETE -> Para borrar datos

Las diferencias entre PUT/POST son bastante filosóficas así que no entraré en ellas. Pero básicamente si quieres realizar un método que haga una alta en la BBDD:

public int PostData(MyData data) {... }

Dado que el método empieza por Post, será enrutado mediante el verbo HTTP post. Los datos que recibes son de tipo MyData (ahí tienes las propiedades que necesites, habitualmente el ID y los datos asociados).

Dado que es una petición POST los datos viajan por el cuerpo de la petición (no en la URL). Pueden viajar codificados de varias maneras, p.ej. mediante application/x-www-form-urlencoded (submit de form) o bien mediante JSOn. WebApi entiende ambas de serie.

Por lo tanto la idea es:

1. Lectura de datos -> HTTP GET (Métodos Get*)

2. Modificación de datos -> HTTP POST/PUT (Métodos Post* y Put*)

3. Eliminación de datos -> HTTP DELETE (Métodos Delete*)

Saludos!

re: ¿Están tus servicios REST en otro servidor?

MetalTux — Mon, 04 Mar 2013 12:34:37 GMT

Excelente artículo Eduard...

Me gustaría hacerte una pregunta, si puedes orientarme... he creado una WebApi simple, a través de la cual obtengo listados de datos sin problemas, realizo búsquedas y obtengo el contenido de un item específico... todo funciona a la perfección... pero lo que no sé como puedo realizar son los procesos de Ingresos de Datos y Actualización de Datos...

Sucede que hay una columna en mi tabla que puede llegar facilmente a los 4000 caracteres, esto porque almacena texto de cuentos (por ejemplo, Blanca Nieves tiene más de 12000 caracteres)... el contenido del cuento lo trato en otra tabla dividiendo el texto por cantidades de caracteres... por ejemplo para Blanca Nieves tengo el contenido en 4 registros distintos...

¿Existe alguna forma de poder realizar Ingreso de datos mediante WebApi con esta cantidad de datos?

Saludos cordiales...

re: Como hacer seguros tus servicios WebApi

Julio Avellaneda — Mon, 25 Feb 2013 13:39:35 GMT

Realmente un gran post me gustaría añadir un par de comentarios, 1. siempre que se deban enviar datos sensibles (y no solo aplica para web api) deberiamos usar https, 2. lo del hash es una técnica comunmente usada, y no esta mal, sin embargo he visto como en estos días aún se sigue usando MD5 que ya esta roto (deberiamos usar SHA512), otro error común es que no crean hash diferentes, siempre usan el mismo, y para este punto tu ejemplo es excelente!

Gracias por compartir tu conocimiento, saludos!

re: Inyección de dependencias per-request en MVC4 y WebApi

andyie — Fri, 22 Feb 2013 21:55:51 GMT

Hola Eduard, estoy usando tu estrategia en una aplicación mixta (MVC y WebAPI). Una de mis paginas tiene cerca de 10 request al webapi para diferentes datos que requiero en la interfaz ... Lamentablemente casi siempre recibo errorres como este en uno o dos del los request enviados:

* The context cannot be used while the model is being created

* The connection was not closed. The connection's current state is connecting

* The type 'XXXX' has been mapped more than once.

Mi aplicación esta compuesta de una capa de modelo (EF), una capa de repositorios, y una capa de servicios que convierten las entidades en POCOs ....

He estado varios dias intentando encontrar que estoy haciendo mal, pero no logro encontrar el problema. De casualidad tienes alguna sugerencia?

re: Como hacer seguros tus servicios WebApi

José A. Fernández — Wed, 20 Feb 2013 14:02:44 GMT

Excelente post!

En algunas aplicaciones que necesitan "exponer datos" lo hago con webapi y con la "idea de oAuth" que explicas.

Como es de puro conocimiento es la tecnica que utilizan la mayoria de las API publica de los servicios mas conocidos (Facebook, Twitter, etc) un key (identificador) y un secret (para encriptar los datos)

Como hacer seguros tus servicios WebApi

Burbujas en .NET — Wed, 20 Feb 2013 11:46:35 GMT

Buenas! Este post surge a raíz del comentario de Felix Manuel en mi post anterior Inyección de dependencias