26/02/2010 08:46 por
zorry
En los servicios WCF se puede establecer seguridad a nivel de mensaje. Para poderlo hacer, hay que instalar un certificado, que será el que se emplee para cifrar el contenido que se requiera.
Ahora bien, un certificado generalmente es instalado por un administrador, pero un servicio generalmente corre con credenciales de usuario restringido. Con lo que normalmente no tendrá privilegios para poder acceder al fichero de la clave privada de los certificados. Vamos a ver cómo manejar esta situación.
Más...
9f2a1c25-ca4f-4c01-a052-01ffb76c7867|1|5.0
16/02/2010 12:48 por
zorry
Me comenta mi amigo Sergio, en relación a mi artículo de acceso a un certificado, que hay muchas veces que al reiniciar la máquina, se corrompe el certificado de desarrollo, con lo que tienen que eliminarlo y volverlo a crear. Este artículo cuenta cómo eliminar el certificado para poder volverlo a crear.
Más...
96ca01a4-5244-4a5e-b584-99dc6ca911ae|0|.0
29/01/2010 13:18 por
zorry
Vamos a aprender a firmar un documento Xml con el estándar W3C Xml-DSig. En el mundo .Net, la clase SignedXml nos implementa gran parte del estándar, con lo que con unas cuantas líneas podremos implementar una tarea tediosa tiempo atrás.
Más...
4fc0f820-9766-42b1-b4fa-5153c94668f0|6|5.0
29/01/2010 10:45 por
zorry
Vamos a aprender a leer un certificado del almacén de certificados de Windows. Esta tarea es bastante sencilla. Para poder programar con certificados de usuario X509 sin necesidad de tener que comprar un certificado a una entidad certificadora, podemos crear un certificado de pruebas. Este certificado únicamente nos valdrá en nuestra máquina local, ya que no posee una ruta de certificación completa y puede que en algunos escenarios avanzados no responda correctamente, pero para nuestro uso será más que suficiente.
Más...
1772fe77-068e-46ac-8be5-e25e8537ec2d|5|4.8
29/12/2007 08:12 por
zorry
Revisando el fix que hice ayer, y debido sobre todo a que no me gusta hacer modificaciones en librerías que no dependen de mí (sobre todo, para evitar que en una nueva release del AjaxControlToolkit me machaquen los cambios), me he fijado en una propiedad del ToolkitScriptManager denominada CombineScriptsHandlerUrl. Esta propiedad permite especificar un handler específico para manejar la combinación de todos los script del AjaxControlToolkit. De modo que me dispongo a deshacer los cambios que hice ayer, y hago varios cambios en mi aplicación web:
- En la definición del ToolkitScriptManager, he incluído el siguiente atributo: CombineScriptsHandlerUrl="~/CombineScriptsHandler.ashx"
- He creado un nuevo handler en la aplicación con el nombre definido en el nombre anterior. En el archivo ashx he introducido el siguiente código:
1: <%@ WebHandler Language="C#" Class="CombineScriptsHandler" %>
2:
3: using System;
4: using System.Web;
5: using AjaxControlToolkit;
6:
7: public class CombineScriptsHandler : IHttpHandler
8: {
9: /// <summary>
10: /// ProcessRequest implementation outputs the combined script file
11: /// </summary>
12: /// <param name="context"></param>
13: public void ProcessRequest(HttpContext context)
14: {
15: if (!ToolkitScriptManager.OutputCombinedScriptFile(context))
16: {
17: throw new InvalidOperationException("Combined script file output failed unexpectedly.");
18: }
19: }
20:
21: /// <summary>
22: /// IsReusable implementation returns true since this class is stateless
23: /// </summary>
24: public bool IsReusable
25: {
26: get { return true; }
27: }
28: }
29:
Con estos cambios por fin he conseguido que la aplicación funcione correctamente en modo cookieless, y sin los problemas de javascript que me estaba encontrando anteriormente.
82354f83-f178-464d-8e98-09ec589bb2f2|0|.0