Kohana 3.1 Web Services Bootstrapping Based on Environment and Stored Like A Session

We are building a n-tiered style application in Kohana 3.1 which distributes JSONP开发者_Python百科 powered widgets to our partners based on a partner_id.

Each partner needs to be able to call a widget and specify an environment parameter: test OR production with the initial call, which will be used to select the appropriate database.

We need our bootstrap to watch for $_REQUEST['environment'] variable and then to maintain the state of that variable whenever the partner makes a call to the widget service.

The problem is, that all requests in the application use Bootstrap.php, but many of the requests are internal - i.e. they do not come with a partner_id or environment variable. We tried to use sessions to store these, but as these are server-to-server GET/POST calls, it does not seem possible to store and recall the session id in a cookie on the server (this is browser-less GET).

Does anyone have any suggestions? We realise we could pass the environment variable with every single call internal or external, but this does not seem very robust.

We have a config file which stores partner settings (indexed by partner_id), such as the width and height of the widget and we thought about storing the partner's environment in here, but not all calls to the server would be made by a partner, so we would still need another way to trigger the environment for other calls and select the correct DB.

We also thought of storing a flat file for the partner which maintains the last requested environment, but again, as we have many internal requests after the initial one, we don't always have a knowledge (i.e. we don't usually care) which partner_id is used in the initial call.

Hope this makes sense...!

The solution would be to call the models and methods that are needed to 'do stuff' from a single controller, keeping the partner_id only in the controller and sending the requested data back once all of the 'do stuff' methods have been run, as per the MVC model.

i.e., request from partner -> route -> controller -> calls models etc -> passes back to controller -> returns view to partner

That allows the partner_id to be kept by the controller and only passed to whatever models require it to 'do stuff', keeping within the MVC framework.

If you've not kept within the confines of MVC, then things will obviously get more complex and you'll need to store the variable somewhere.