Security Software

Joel, that was perfect, sir. Full points given.

If I may ask... How did you know to look there? And why would it have suddenly become broken?

Hi Mark,

I was able to determine the affected item by the item ID given in the error message (130073351461551152955). That error message will be changed to include the item name instead.

Also, I know that this is slightly modified behavior in the forthcoming APEX 4.1.1 patch set, which will be documented in the patch set notes.

Joel

Joel, thank you again for the detective work.

For future reference for everyone else, what Joel did was cool, but I didn't know how to do it -- how to find the object associated with that long ID string. Here's how:

In the SQL Workshop > SQL Commands, execute this query: select item_id, page_id, region, item_name from apex_application_page_items where item_id = '12345678901234567890'

using the ID string from your error message.

Great !

And now what would be the trick if he would have to use value of P21_CUSTOMER_BANNER in his next page ?

I am experiencing the issue and can't find any solution.

Best,
Sébastien

Sébastien,

Maybe you need to change "Save Session State" to "Yes"?

Joel

Hi jkallman

thank you for the answer.
Already tried this and get the same kind of session state violation error.

Best
Sébastien

I have the same problem. Apps falling over everywhere since the 4.1.1 update was applied.

2 separate problems, one relating to zero session ID usage, which used to work fine, and also a common thread of display items with session state set to save as reported in this thread. Not sure how often this technique has been used, I have hundreds of pages to check - but it was valid before, and perhaps a query ought to have been made available to run before applying the patch. Or even now would be good.

My hosting service have shrugged their shoulders and left me to it. Five days of severely compromised operations from avoidable problems it would seem. Thank you Revion.

Hi Chris,

to give some additional information. The error message "Session state protection violation: This may be caused by manual alteration of protected page item ..." only occurs if the value of the "Display Only" page item where "Save State" = Yes is being modified with JavaScript. It should not occur for a regular "Display Only" page item which saves state.

Can you please provide more information what is not working related to the usage of zero session ID. Might be a good idea to open up a new thread.

Regarding the "Session state protection violation" problem, I can offer that I have a look at your application to identify the root cause of the issue. You can send me some instructions and login information to patrick dot wolf at oracle dot com

Regards
Patrick
-----------
My Blog: http://www.inside-oracle-apex.com
APEX Plug-Ins: http://apex.oracle.com/plugins
Twitter: http://www.twitter.com/patrickwolf

Thank you Patrick, I would very much appreciate your input, and I have sent instructions and credentials via email.

Regards
CS

Patrick
To ensure I am not wasting your time I have isolated several examples of page items which are the subject of the session state protection error and which are not set by javascript functions (although they are referenced in javascript functions). It appears to me that page items defined as display only (or becoming so by condition) are caught up, perhaps inadvertently, by this new approach.

Some items in question map to database columns within the scope of a page's standard apex DML routines. These page items need to be saved to the database even if their value is established by page events and processes other than user input. I guess I could set their session state by stealth, and submit them in a report region refresh, although there is no guarantee this would work if you are dynamically generating a minimalist SQL update statement. I think the previous approach - allowing the developer to specify the items to be saved - has a lot to commend it.

I recently discovered that my fallback plan to use the "set_compatability_mode" procedure to revert to 4.0 compatibility mode, appears not to resolve this particular problem. Reverting to a server which has not run the 4.1.1 update DID fix the "session state protection" error, but this option is not viable beyond the next few days.

Regards
CS

Since other people might have the same issue, let me add my situation (after the upgrade from 4.0 to 4.1.1.00.23).

We have several hidden items that got this message after the upgrade, and didn't get it before. The problem in this case is the "Value Protected" property. It was set to Yes, which apparently didn't work properly in 4.0. Setting it to No resolved our problem.

I have the same problem with fields that are read only and displayed as Text Field. All I had to do to fix the problem is click on the 'Text' item below the Display As field.

That is friggin obscure!! How in the world did you figure that out? And why does it work?

Joel, how are you? I have to admit to not reading the documentation and stumbling into this because it stopped working just like the others. But it sure is comforting to be able to find the answers on the forum. Thanks for the great work you guys always do!

Regards
Bill

Edited by: sk**** on Sep 6, 2012 4:32 AM

It is possible so save in database display only item?