Proveedor de identificación falso abierto para propósitos de prueba

Question

Al igual que SO, voy a depender de muchos proveedores de Open ID para proporcionar autenticación de usuario y usaré mis propios métodos de autorización. pero todavía estoy en fase de desarrollo, y no quiero trabajar con proveedores de OpenID reales en la actualidad, ¿qué enfoque puedo usar para evaluar a mis usuarios y sus actividades en el sitio web (sin TDD), para emular usuarios reales pero no realmente usar proveedores de Open ID.

No es necesario realizar una transferencia automática de usuarios a servidores OpenID reales (cuando se pasa al modo de producción) ya que los usuarios actuales son solo para propósitos de prueba y código de prueba de unidad.

Supongo que necesito una capa de Servicio al Usuario que brinde una manera muy abstracta de tratar con los usuarios, para que el cambio a los proveedores de Open ID reales pueda ser fluido en el futuro y no afecte la lógica de mi código escrito.

Utilizando C# .Net 4, ASP.Net MVC 3, Ninject

Answer 1

DotNetOpenAuth proporciona tanto porciones de servidor como de cliente de OpenID y puede usarse para ejecutar su propio proveedor de OpenID para pruebas locales.

• que de nuestros miembros del sitio sus propias OpenID con el soporte del proveedor incluido en esta biblioteca.

• Ejemplo de sitios web de proveedores y proveedores que le muestran cómo hacerlo.

Answer 2

Simplemente registro mi ID de usuario de prueba como con diversas organizaciones. No veo nada de malo en eso. Veo las diferentes respuestas y sus diferencias.

Me pareció terriblemente fácil de codificar para el consumidor openid. Solo necesito entender la secuencia de respuestas. Dibuje el diagrama de secuencia de UML para ayudarlo a comprender antes de comenzar a codificar. No es necesario falsificar OpenId. De lo contrario, prepare un servidor openid usted mismo.

Answer 3

Sus servicios no deben depender de OpenID. Simplemente haga que OpenID se conecte a un módulo de autenticación para proporcionar un principal de usuario local. En desarrollo, puede hacer que el módulo de autenticación devuelva un principal de usuario falso con los permisos que desee.

En un entorno beta, puede activar OpenID y utilizar cuentas de prueba desde cualquier proveedor de OpenID. Tener que iniciar sesión durante la fase de desarrollo ralentizará a todos los desarrolladores. Cualquier error de autenticación o corte de internet matará la productividad de todos.