2012-07-31 6 views
8

Estoy considerando configurar el uso de Nuget en el nivel de intranet (se supone que muchos equipos de mi compañía lo usan).
He examinado brevemente a través de algunos tutoriales + capítulos correspondientes en Pro Nuget libro, sin embargo todavía tienen algunas pregunta que queda hasta el momento:Feed de Nuget a nivel de intranet privado: Personalización de seguridad integrada de Windows

  1. Como hacer ventanas de seguridad integrado que trabaja en alimentación privada sin problemas y personalizar derechos de acceso para alimentación Nuget privada (por ejemplo, otorgar a todos para que obtengan paquetes pero otorgarles solo a varios usuarios/grupos de dominio);
  2. ¿Cómo se permite a los desarrolladores enviar paquetes a fuentes privadas sin tener api key?
  3. Cómo salvar a los desarrolladores de cometer un error tan tonto como empujar el paquete a la alimentación pública? ¿Es eso suficiente para no configurar api key para la alimentación pública como predeterminado?

¿Alguien ha enfrentado con uno de estos casos? Cualquier sugerencia es apreciada.

Gracias!

+1

Las razones que ha enumerado aquí son algunas de las inspiraciones de por qué creamos [ProGet] (http://inedo.com/proget/download), por lo que si está dispuesto a gastar un poco de dinero puede hacerlo todas las cosas que enumeró con bastante facilidad en la versión Enterprise. –

+0

Gracias por su respuesta, ProGet se ve bien. Lo veré más de cerca –

+1

Puede que le interese esta solicitud de fork y pull en el proyecto NuGetGallery para agregar soporte para esto. https://github.com/NuGet/NuGetGallery/pull/562 –

Respuesta

4

no probé esto hasta ahora, pero siguiendo estas instrucciones: http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds

me acaba de crear un recurso compartido de red en el servidor que aloja la alimentación, con acceso de escritura al grupo de anuncios específicos de los desarrolladores.

De esta forma, su repositorio es público y solo algunas personas pueden agregarle paquetes.

Incluso después, si tiene un servidor de integración continua, podría permitir el acceso al recurso compartido de archivos (o la clave API) solo a los paquetes de creación de cuentas. De esta forma, los paquetes se publican automáticamente después de pasar las pruebas automáticas.

+0

Compartir en red parece prometedor para ser la mejor opción para elegir en mi caso. Lo más probable es que mi equipo lo siga. –

+1

Poniendo poca actualización aquí. Después de configurar el uso compartido de archivos, hemos configurado una alimentación nuget privada alojada en IIS (lo cual es extremadamente fácil de hacer: [pasos aquí] (http://docs.nuget.org/docs/creating-packages/hosting-your-own). -nuget-feeds) y la gestión de los derechos de acceso nuget se realiza a través de IIS. –

+0

Las mejores opciones son publicar en el feed NuGet a través de nuget push y utilizar las credenciales de paso y autenticación de IIS para administrar la seguridad. De todos modos, puede administrar la seguridad en el nivel de FileSystem, pero no tiene que abrir un recurso compartido y no tiene que lidiar con problemas de indexación al eliminar paquetes a través de un recurso compartido. –

Cuestiones relacionadas