This portal is to open public enhancement requests against products and services offered by the IBM Data & AI organization. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Search existing ideas
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updateson them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,
Post an idea
Upvote ideas that matter most to you
Get feedback from the IBM team to refine your idea
Specific links you will want to bookmark for future use
Allow remote query execution inside a TRUSTED CONTEXT
A customer that has some customized "auditing" built on triggers would like to be able to differentiate the real user behind the application server.
In theory they could use SET SESSION AUTHORIZATION to achieve this, either directly or better yet, inside a TRUSTED CONTEXT connection. Unfortunately, as with most Informix customers, they have several databases used by the same application with remote queries (directly, through views or synonyms).
And a session after using SET SESSION AUTHORIZATION cannot do remote queries. It will raise error:
-32504 Operations on remote objects are not allowed after session level set.
You cannot access objects in remote databases when your current session sensitivity level differs from that of your login session. Return to the sensitivity level of your login session to access remote data.
This makes the feature unusable in most of our customers, which turns a good feature into a nearly useless functionality.
In 2011 I faced the same situation in a customer that wanted to expose legacy 4GL code as web services. At the time we opened idsdb00222856, which was classified as an RFE but apparently it got lost in the RFE system evolutions over the years.
We understand the security constraints around this topic. A DBA of instance A could eventually gain access to instance B, by impersonating a user in instance A that has access to instance B. But this concern ignores the fact that in most if not all situations, the DBA and security teams of two instances that have connection between them are the same, and under the same organization. Even so, this could be controlled by a parameter at instance level or an option at database level. Just to maintain maximum security and backward compatibility
Do not place IBM confidential, company confidential, or personal information into any field.