php and application modernization

One of the problems we are struggling with at the moment is how to put a new php interface onto the products we provide. At first glance it seems pretty easy, all we have to do is create pages that provide the same functionality as the panels and menus we have.

We felt pretty confident about how the use of php would give us a fairly simple yet effective way to modernize (just make it look pretty, its already got the latest technology) the current product suite. We even decided we would use templates and create generic panels that could be carried across all of the products. Then we hit the wall, we had hoped to be able to sign on to the system at the start of the application process and use the same connection to do all of the work across subsequent pages. This would allow us to make sure the user profile running the request had the authority to do so and keep system security intact. But our plan to use session variables to carry the connection information does not work, you cannot store a resource ID in a session variable. So each time we need to connect to run one of the i5_* functions we would have to issue the i5_conn request before running the command, program or DB request.

We can do this simply by storing the user name and password in the session variables and using them each time, this has its obvious downsides! So we looked at how to store the information on the server and use it each time, the problem with that was each of the i5_* functions requires the connection resource to be passed in. You do have the possibility of using a default connection but that would have its own problems as we want to ensure security integrity.

The i5_conn function is none persistent and when you look at how the process works in the background its easy to see why its done that way, each time you request a page from the server you get pot luck as to which server responder gets your request, it could be the same as the one you started with but may not! This means it cannot store local information about the connection for the next time it sees a request.

So we have spoken with Zend and hope they can offer an alternative, we only need the pretty interface over our existing code at the moment but looking forward even if we had done the application from the start we would have this problem?

Some how they need to add a kind of cookie process to the back end functions, when they are called they need to be able to set the environment for the user and store a map that can be keyed by the user, then if a request comes through it will have a key that corresponds to a user profile handle, the key can be verfied against the source somehow to esnure its not been modified or overridden! The map entries can expire in much the same way as a client cookie does and released on log out to stop a build up or theft of somekind.

At this point we are stuck so If you have a possible solution let us know.

Chris….

4 thoughts on “php and application modernization”

  1. Yes we looked at it but didnt try it out! I didnt think the resource would survive even if we serialized it so didnt bother to try it out…

    I will try it out and post if it works..

    Chris…

  2. No it doesnt work! I went to the link and re-read the info, here it is.

    “The value to be serialized. serialize() handles all types, except the resource-type. You can even serialize() arrays that contain references to itself. Circular references inside the array/object you are serialize()ing will also be stored. Any other reference will be lost.”

    Looks like I was right, serialize wont hold a resource type! Thanks for the update though, if you think of anything else we will ty it out…

    Chris…

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.