Creating and Dropping Trusted Context

Dear All I seem to be having trouble understanding how trusted contexts work. I thought understood them, but started to get some strange issued once I created on and started connecting through the INFORMIX_PDO driver. Although I don't believe PHP, PDO or the underlying ODBC are at fault here... To keep things simple I ran the following test and now wonder if anyone can explain the result. We have an IDS 11.70.FC7GE database server instance holding a number of database: trip, support, report, etc... I created a file containing the SQL to create a trusted context. "create_trust.sql" I created another file containing the SQL to drop said context. "drop_trust.sql" Now my understanding is that you create a trusted context in the database, or databases, you require. Each database has its own separate trusted context object in the same way has it has its own separate set of tables, etc. Now, when logged on to the server I can do the following: > dbaccess trip create_trust.sql Database selected. Trusted context created. SETSESSIONAUTH privilege granted. Database closed. > dbaccess report drop_trust.sql Database selected. Trusted context dropped. Database closed. So, in short, I connected to the "trip" database and created the context. Then connected to the "report" database and dropped it! How can this be? Best regards Paul

A trusted context, while you must be connected to a database to create, is a server level object which is created in the sysuser database. Therefore you can access it or drop it in any database. Art Art S. Kagel, Principal Consultant Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Fri, Nov 8, 2013 at 1:08 AM, PAUL MAHONEY <ptm@xact.co.uk> wrote: > Dear All > > I seem to be having trouble understanding how trusted contexts work. I > thought > understood them, but started to get some strange issued once I created on > and > started connecting through the INFORMIX_PDO driver. Although I don't > believe > PHP, PDO or the underlying ODBC are at fault here... > > To keep things simple I ran the following test and now wonder if anyone can > explain the result. > > We have an IDS 11.70.FC7GE database server instance holding a number of > database: trip, support, report, etc... > > I created a file containing the SQL to create a trusted context. > "create_trust.sql" > > I created another file containing the SQL to drop said context. > "drop_trust.sql" > > Now my understanding is that you create a trusted context in the database, > or > databases, you require. Each database has its own separate trusted context > object in the same way has it has its own separate set of tables, etc. > > Now, when logged on to the server I can do the following: > > > dbaccess trip create_trust.sql > Database selected. > Trusted context created. > SETSESSIONAUTH privilege granted. > Database closed. > > > dbaccess report drop_trust.sql > Database selected. > Trusted context dropped. > Database closed. > > So, in short, I connected to the "trip" database and created the context. > Then > connected to the "report" database and dropped it! How can this be? > > Best regards > > Paul > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001a1134b65e7a736504eaaddac4

Thanks Art, that makes sense as Informix security has always been and the server level. Based on things like /etc/hosts.equiv etc. So now on to my next puzzle... Remember I have 3 databases: trip, support and report So I use dbaccess to connect to database "trip" and create the trust context. Then I run my test script that connects to the "report" database using TRUSTEDCONTEXT=1; in the connection string. When I do this I get the following error: 'The database specified (trip) is not associated with a trusted context definition' Well, didn't I just create it? And I'm connecting to database report, not trip... So now I use dbaccess to connect to the "report" database, and drop and re-create the same trust context. Repeat my test and it now works. Any clues what's going on?

No idea. Time to open a support call and let IBM sort it out. Art Art S. Kagel, Principal Consultant Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Sun, Nov 10, 2013 at 11:58 PM, PAUL MAHONEY <ptm@xact.co.uk> wrote: > Thanks Art, that makes sense as Informix security has always been and the > server level. Based on things like /etc/hosts.equiv etc. So now on to my > next > puzzle... > > Remember I have 3 databases: trip, support and report > > So I use dbaccess to connect to database "trip" and create the trust > context. > Then I run my test script that connects to the "report" database using > TRUSTEDCONTEXT=1; in the connection string. When I do this I get the > following > error: > > 'The database specified (trip) is not associated with a trusted context > definition' > > Well, didn't I just create it? And I'm connecting to database report, not > trip... > > So now I use dbaccess to connect to the "report" database, and drop and > re-create the same trust context. Repeat my test and it now works. > > Any clues what's going on? > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001a11c3c4febb0af504eae4ef43