2010-09-11 21 views
8

Estoy empezando con el desarrollo de Ruby on Rails y tengo una pregunta sobre el código fuente "privacidad".Ruby on Rails código fuente seguridad/ofuscación

Por lo que sé hasta el momento (no he hecho un despliegue sin embargo, sólo se utiliza RoR en un entorno de desarrollo local), que cuando se implementa una aplicación RoR, todo el código fuente es "visible" en el servidor ?

¿Cómo puedo proteger mi código; ¿por así decirlo? Por protección quiero decir, el objetivo principal es que alguien (, como un administrador del servidor en un proveedor RoR) no pueda "sabotear" el código fácilmente averiguando en qué lugar del código "manipular".

¿Cómo hacen sitios como Shopify, Yellowpages etc. que usan RoR, aseguran que su código no sea "saboteado"?

ACTUALIZACIÓN Lo que realmente estoy buscando es, supongo que si tengo algo de código que está haciendo transacciones con tarjeta de crédito, no quiero algún empleado pícaro leer "el código fuente de texto sin formato" y sabotear mi sitio web, por decirlo leyendo mi código fuente y luego cargando a todos los usuarios registrados $ 10 como una mordaza. ¿Cómo evito ese tipo de cosas?

+1

Sitios como Shopify, etc. Yellowpages más probable es ejecutar su propio servidor, por lo que no le importa el administrador del servidor puede leer el código. Si utiliza un proveedor de alojamiento de buena fe, no creo que sea necesario proteger su código. – Mischa

+0

@captiontokyo, ¿entonces lo que dices es que tampoco hay necesidad de ofuscar el código? – Zabba

+2

Si acepta pagos, no haga los suyos propios ni almacene los datos en sus servidores. Ir a través de lugares como Fastspring y/o Paypal. La cantidad de regulaciones es alucinante y todo lo que se necesita es un error de su parte para ponerlo en un charco legal. – user370731

Respuesta

13

Similar al punto de Matt Briggs es que si no confías en tu proveedor de alojamiento web, estás solucionando el problema incorrecto. Si tu proveedor de alojamiento web quiere robar tus datos, paralizar tu sitio web, redireccionar a tus usuarios, etc. nada puede detenerlos. Incluso si el código es código binario completamente compilado y escrito en ensamblador, su administrador aún podría encontrar un truco, reemplazar recursos o reemplazar su código por completo. Moraleja de la historia, encuentre un servidor web en el que confíe, no se moleste en ofuscar su código

+0

Bueno, ¿cómo se puede confiar en cualquier tercero de todos modos? Cuando tengo algún propósito "X" en mente, y tengo que depender de un servidor web que no tengo control, ¿cómo puedo "confiar" en ellos de todos modos? Esa es toda la pregunta quemándome en mi mente. – Zabba

+0

@Zabba Estás siendo un poco paranoico aquí. En un país tan feliz como el nuestro, hacer algo así sería extremadamente estúpido de su parte. – NullUserException

+3

Probablemente, la preocupación más legítima es estar en un servidor compartido y no estar configurado correctamente, lo que permite que se incluyan los datos o el código. La forma en que más compañías lo solucionan es comprando y asegurando sus propios servidores. Incluso con eso, pocos alojan sus servidores en casa. Los servidores del servidor están motivados para NO robarle porque (a) es ilegal y no quieren ser demandados y (b) si robaron su código, nadie usaría sus servicios. Sin ánimo de ofender, pero su código probablemente no valga más que la suma de los ingresos de todos sus clientes, incluso por un mes. – userx

9

Al final del día, hay confianza. Si su administrador quiere joderlo, lo hará, y la ofuscación no hará mucho para detenerlo.

+0

Si una aplicación estaba en ensamblador x86, eso la haría menos susceptible, ¿no? – Zabba

+2

Probablemente, pero el chico controla el servidor. Si él quiere, podría fingir el diseño de su aplicación, colocarla en otro lugar y redirigir a la gente de allí. O simplemente podría buscar en su base de datos, que generalmente contiene más cosas valiosas y delicadas que su código de aplicación de todos modos –

+0

Zabba-Only si el administrador no sabe ensamblar. – user370731

3

Dudo mucho que un servicio de alojamiento confiable altere su código. Están lo suficientemente ocupados corriendo sus servidores. Y si quisieran, no hay mucho que puedan hacer para detenerlos. La ofuscación de código (en cualquier idioma) es una tontería.

En cuanto a sus preocupaciones de seguridad, solo espero que no almacene ninguna información de tarjeta de crédito en su sitio web. Debe cumplir con PCI standards para hacer eso, y eso no es una tarea fácil de lograr. Almacenar información CC sin ser compatible con PCI es ilegal.

Así que tendrá que usar una pasarela de pago (como PayPal o Authorize.net) para sus pagos, y creo que el usuario podrá ver lo que se le está cargando.

9

Según mi experiencia, cuando vende un producto que se implementa en el servidor del cliente. Yo uso

http://rubyencoder.com/

Funciona en muchos plataforma desde su cargador. Pero como dijo otro, los rieles deberían estar abiertos.

+0

Esto se ve excelente, gracias. – ndbroadbent

+0

¿Hay una alternativa de código abierto? –

1

Una empresa de hosting nunca tocará o investigará su código, a menos que esté haciendo cosas que duelen en el servidor (como bucles infinitos, devorando toda la CPU), e incluso en ese caso, simplemente bloquearán esa página o url.

Me imagino que si despliega su aplicación en una intranet de una empresa, y también tienen sus desarrolladores, podría temer perder comisiones de mantenimiento y soporte porque se harían cargo ellos mismos. Pero esas cosas que cubre con contratos.

Se supone que las personas que tienen acceso directo a su código fuente de rubí son compañeros de trabajo o socios, si existe una relación comercial clara, y normalmente esta relación comercial vale más. Si no confía en sus compañeros de trabajo o las personas con las que trabaja o trabaja, entonces creo que debería reconsiderar su posición.

Incluso creo que ser lo más flexible posible con los clientes (aquí está la fuente, puede editarlo si lo desea), generalmente hace que confíen aún más en usted y que sea más probable que le devuelva la llamada.