1

is it possible to make the python as the web server and the front end is codeigniter?

For some reasons:

  • database security - like when you are saving data. the codeigniter will pass the data to python basehttpserver / or maybe flask (but i have not yet done the flask before)
  • SQL Injection.

it's like for example. front end codeigniter

  • form - send data.

back end python web service

  • receives data - will serve as an API. and the python will be the one in charge of saving data in MySQLdb.
Vincent
  • 852
  • 6
  • 29
  • 67
  • The webserver doesn't handle database security. Why do you think this is a good setup? – Blender Feb 27 '14 at 05:17
  • @Blender .. i was thinking that. sending data to python web service which will serve as an API for codeigniter. – Vincent Feb 27 '14 at 05:26
  • 1
    There is no reason you can't do this, this is similar to a Service Orientated Architecture or multi tier application. The major requirement is that you define good interfaces between your services, the language/technology stack used to build the service is then no longer relevant. If you are doing this for security reasons then you should also ensure that there is appropriate network separation between the services (ie the database is behind a firewall and isolated from the internet). This can also be a way to improve scalability as the second tier can have additional load balancing. – Tim Feb 27 '14 at 05:39
  • Yes @Tim, i was thinking of doing a separate network to ensure the security of my database. like making a two servers for the front end and the back end. – Vincent Feb 27 '14 at 06:13
  • @Tim, but making a second tier, will that make my CI's model and controller useless? maybe I should make another selections of framework like django or flask? Because I was thinking that my model and controller will be irrelevant when I integrate python as the one that will save the data, right? – Vincent Feb 27 '14 at 07:02
  • 2
    The controller and views are still important, although your models will be used in a different way. First though what is your actual use case here? Do you just wanting to avoid SQL injection and prevent common security vulnerabilities, in which case follow ProgrammerDan's advise and just use either CodeIgniter (or Django). The kind of architecture you are asking about is more complex, unless you security requirements specifically require the isolation follow the golden rule of architecture and keep removing things until you are left with the simplest solution that meets the requirements. – Tim Feb 27 '14 at 07:16

1 Answers1

2

In theory I don't see why this would be impossible.

You could easily write a web application using codeigniter and have the controllers just pass data along to a python based web service. If you're interested in a fully decoupled front-end/back-end, you could also use a queuing layer (such as RabbitMQ) in between the data entry facilities in your CI program, and the persistence web services in Python.

That said, I'm not clear why you would want to. CodeIgniter is PHP, and includes some very excellent data modelling components that integrate fully into the overall framework. Long story short, if you're using CodeIgniter, just have it connect to MySQL and do the data persistence for you.

Likewise, if you'd prefer to code your persistence in Python, why not just use Django? It's a fully realized Python web framework, and also features an excellent ORM and support for MySQL.

I don't really see how either technology gives you clear benefits, provided they are both used properly, for database security. Both have built-in methodologies for "cleansing" user provided data to prevent SQL injection (notes for Django and notes for CodeIgniter)

There are a great many other posts on StackOverflow dealing with preventing SQL injection with CodeIgniter and other frameworks. Just using python, or decoupling your front-end and back-end, will not provide you any additional security or protection guarantees. The only way to do that is to carefully architect your interactions with databases, using all the tools provided you by whatever framework you are using, or creating their equivalents if none are available (or switch to a better toolset).

Edit - expansion

Based on the comments above I figured it was actually worth writing a little more about the potential advantages and real challenges of a decoupled infrastructure.

In principle, it's easy to decouple a front-end from a more isolated backend. You could leverage in either Django or likely CodeIgniter (although I haven't personally seen it done in CI, just in Django) the existing model infrastructure, but deal with model objects in memory only on the frontend, and expand on the existing ORM functionality to use your backend services to actually store and retrieve data from a persistence layer (your database).

Practically, this can become quite a bit of work to do right. To gain the security advantages you desire, your decoupled backend needs to deal with the frontend as if in principle it is "hostile", or at the least, untrustworthy. So, be sure that you implement a method for the frontend to reliably authenticate itself to the backend. Ensure that all traffic is minimally using SSL between the frontend and the backend. Consider carefully your services architecture (the SOA layer in front of your backend logic) and make sure your APIs, where possible, are MECE (Mutually exclusive, collectively exhaustive).

I'm sure I'm missing some basic principles, but having recently participated in the design and build of a system along these lines I can assure you that the complexity can very quickly explode, so careful architectural discipline and adherence to both MECE and MVP (minimum viable product) is critical. A decoupled infrastructure can be an amazing end-product if it fits the need, and in use cases I've worked with it has been extremely effective. It isn't a one-size-fits-all, though, and hopefully some of the extra description here can help you make a more informed choice.

Hopefully this helps round out the topic answer. Basic principles: Design for what you need. Don't conflate complicated with secure. Simple can be secure, as can complex, but complexity breeds room for hard-to-plug security vulnerabilities, and simple gives the illusion of security by seeming easy. No approach guarantees a positive outcome, so don't try to cut corners; spend as much time as you can in research and design to minimize your time building, refactoring, and fixing.

Community
  • 1
  • 1
ProgrammerDan
  • 871
  • 7
  • 17
  • 1
    Your suggestion is correct for a simple web application but having a second tier isolated from the front-end application is a common way of providing additional security, especially if the database contains sensitive customer data that needs to be secured. This is also common in systems where you might not have or do not want a database to be directly accessible from a DMZ. – Tim Feb 27 '14 at 06:32
  • Sure, all examples are context-sensitive. I think the core principle is choose your technology stack based on your true needs, but don't fall victim to a false expectation that decoupling promotes security. It doesn't. In fact, naive decoupling dramatically increases potential exposure to security flaws. For instance, traffic between DMZ and non-DMZ systems might be improperly secured, or an assumption that since the secure database is "not" externally accessible that user accounts don't need close curation and secure volumes aren't needed .. these are commons design failures when decoupling. – ProgrammerDan Feb 27 '14 at 08:09