This discussion is archived
12 Replies Latest reply: Jan 24, 2013 5:49 AM by Arie Geller RSS

Workaround for Session state protection error on readonly fields needed

ingofa Newbie
Currently Being Moderated
Hello, I'v got an issue that seems to affect a lot applications but although I really dug through the postings, I couldn't find a practicable solution.

I need a solution to have:
- Items that look like "display only"
- but they have to save their state and
- I need to access their value via JavaScript (Ajax, JSON)

This was no problem previously (APEX 3.x) but seems impossible now with Apex 4.1

Please give me any suggestions on how I can have the previous behavior back!

Thanks a lot in advance,
Ingo
  • 1. Re: Workaround for Session state protection error on readonly fields needed
    Arie Geller Guru
    Currently Being Moderated
    Hello Ingo,

    >> This was no problem previously (APEX 3.x) but seems impossible now with Apex 4.1

    What have you done in APEX 3.x that no longer working in APEX 4.1?

    Regards,
    Arie.

    -------------------------------------------------------
    ♦ Please remember to mark appropriate posts as correct/helpful. For the long run, it will benefit us all.

    ♦ Author of Oracle Application Express 3.2 – The Essentials and More
  • 2. Re: Workaround for Session state protection error on readonly fields needed
    ingofa Newbie
    Currently Being Moderated
    Hello Arie,

    I have a simple form on a table with some custom items and a select list.
    The custom items are filled by an on demand process, which is triggered by an on-change-event of the select list and then updates the items by means of JSON (json_from_items, json_SetItems).

    It is required that the custom items manage their state, because some clientside checks and calculations need that, and it is also required that the items must not be changed manually.

    In my previous APEX-Release (3.x, I think 3.4) I used to choose Items of type "Display as Text (escape special characters, saves state)" which is not an option any more with apex 4.

    Both ways I tried now lead to a session state protection violation, although there is no session state protection activated on those items:
    1) Type "Display Only" with "save session state=YES"
    2) Type "Text Field" with readonly condition set to "always"

    It seems there are a lot of others having the same problem, but I couldn't find a sensible solution - some postings seem to be a solution and the thread/question is marked as answered, but it either doesn't work for me or it involves not sensible activities like manually editing an exported application.

    see eg.
    Session state protection violation

    Regards,
    Ingo
  • 3. Re: Workaround for Session state protection error on readonly fields needed
    ingofa Newbie
    Currently Being Moderated
    Hello,
    after some additional investigations I'm quite sure that this is a buggy behavior.
    Some instance thinks, that readonly items MUST be session protected, even if this is turned off.

    Look at this:
    I set one of the above mentioned custom items to "text item"+ "disabled" and all others to "display only" - all these items "Save Session State" = No (!!!).
    So by this situation no checksum for all these items are generated and no session state protection violation happens on submit.

    THEN:
    For the firs "disabled text item" I turn on "readonly condition = always" and => checksums are generated.
    BUT (!!!) EVEN APEX does not think that there are checksum, because when I try to submit that page, i receive:

    "Item ID (3284908824717768) is not an item defined on the current page."

    Looking at the page source, it turns out that this item is the hidden "p_arg_names"-item for the disabled custom item.

    So there must be something going wrong, if APEX does not know its own items.

    I'm afraid I don't have the time to provide a test case at the moment, but this seems to be trivial to reproduce.

    Regards,
    Ingo
  • 4. Re: Workaround for Session state protection error on readonly fields needed
    Arie Geller Guru
    Currently Being Moderated
    Hello Ingo,

    >> Some instance thinks, that readonly items MUST be session protected, even if this is turned off.

    There were some changes in behavior between APEX 3.x and APEX 4.1 and above, where security is concerned. Security was considerably tightened. In some cases, it means that things you could have done with APEX 3.1 are no longer possible with APEX 4.1/4.2.

    By definition, a READ ONLY item is an item that should not be allowed to be changed on the client side, so the APEX engine will not allow you to change its value and submit it. The APEX engine can’t distinguish between your legitimate JavaScript code for changing the value, and illegitimate (malicious) code that do the same.

    If you want a READ ONLY item to save session state, the APEX engine uses a “regular” hidden item for that. The engine will initialize the value of this hidden item to the same value of the READ ONLY item, and will not allow you to change this value on the client side. Security wise, this is the correct and expected behavior.

    By HTML definition, disabled items are not submitted to the server. If you want a disabled item to save session state, The APEX engine will, once again, use a hidden item with the same value, and this item will be the one to be submitted.

    >> "Item ID (3284908824717768) is not an item defined on the current page."

    I was not able to reproduce your situation on apex.oracle.com.

    >> It is required that the custom items manage their state, because some clientside checks and calculations need that, and it is also required that the items must not be changed manually.

    Disabled items are available to JavaScript manipulation, and you can retrieve their value using the built-in function *$v()*. You could display/change their values, but you should not save their session state and submit them (as they are vulnerable to malicious changes). You should not rely on validations and computations that run only on the client side. If these values are dependent on a specific value entered by the user, the cascading values should be reassigned by an after submit process. This is the only way to ensure that these values will not be changed manually.

    Regards,
    Arie.

    -------------------------------------------------------
    ♦ Please remember to mark appropriate posts as correct/helpful. For the long run, it will benefit us all.

    ♦ Author of Oracle Application Express 3.2 – The Essentials and More
  • 5. Re: Workaround for Session state protection error on readonly fields needed
    ingofa Newbie
    Currently Being Moderated
    Arie, thanks a lot for your valuable answer, although I'm not d'accord with you.
    Arie Geller wrote:

    By definition, a READ ONLY item is an item that should not be allowed to be changed on the client side, so the APEX engine will not allow you to change its value and submit it. The APEX engine can’t distinguish between your legitimate JavaScript code for changing the value, and illegitimate (malicious) code that do the same.
    I think here has to be differentiated between read only and display only and that's what has been previously.
    If I want a session state protection, I can turn it on and if i turn it off, i wouldn't suppose it to happen.
    Currently there are two competing mechanisms and in my mentioned example this leads to a loss of functionality.

    >
    >> "Item ID (3284908824717768) is not an item defined on the current page."

    I was not able to reproduce your situation on apex.oracle.com.
    Very simple (at least on my APEX 4.1.1):

    You need a custom text field item.
    You make it disabled, and tell it NOT (!!!) to save its session state.
    You give it a readonly condition of "always".
    Voila: the item tries to save its session state, althoug explicitly told NOT to do, just because of the readonyl condition.
    And then in turn, APEX also is massively surprised by a session state protection item, when there shouldn't be one.

    Please tell me, if my example works for you; otherwise I'll try to make a small "rep case" on apex.oracle.com.

    Regards,
    Ingo
  • 6. Re: Workaround for Session state protection error on readonly fields needed
    Arie Geller Guru
    Currently Being Moderated
    Hello Ingo,

    You are actually presenting two separate issues. The first is about how the APEX engine should deal with disabled/read-only items with regards to their value. The second is how the APEX engine should deal with conflicting definitions of the same item – disable and read-only (and if such a conflict should be allowed).

    >> If I want a session state protection, I can turn it on and if i turn it off, i wouldn't suppose it to happen

    Session state and session state protection are APEX features. The way the APEX engine deals with them should not conflict with general/common standards, like the HTML standard itself. When you choose to define an item as disabled or read-only, according to common practice, its initial value should not be allowed to change on the client side. This behavior should be implemented regardless of whether you want to save the item's session state or not (because this is unique to the APEX engine).

    >> Currently there are two competing mechanisms …

    This is the second issue. I was able to reproduce your scenario, and it’s indeed leading to an error situation. You are defining the same item as both disabled (should not be submitted to the server) and read-only (which APEX do submit to the server). It seems that the APEX engine is rendering the item as read-only, and do submit it to the server, but somehow the instruction not to save session, under the disable option, makes the APEX engine to not recognize the item. I believe that this situation – defining the same item as both disabled and read-only should not be allowed by the Application Builder. I will draw the attention of the development team to the issue, and we’ll see what they are thinking about it.

    Regards,
    Arie.

    -------------------------------------------------------
    ♦ Please remember to mark appropriate posts as correct/helpful. For the long run, it will benefit us all.

    ♦ Author of Oracle Application Express 3.2 – The Essentials and More
  • 7. Re: Workaround for Session state protection error on readonly fields needed
    ingofa Newbie
    Currently Being Moderated
    Hello Arie, thanks again for your answer which seems to give me insight on how the decision, why items should work in a specific way, is made.
    Im just afraid, it doesn't help me with the problem described in my initial post.
    I need a mechanism for presenting values and using these values on the client-side as well as manipulating them (in my case to reflect information based on ajax/on-demand-process calls). All these values are just needed client-side and NOT to be changed by the user or by some client side calculation.

    I need these items to be presented in a way, so that they are good to read and clearly NOT editable.

    Previously I could do that in several ways (e.g. "display as text, saves state"). Currently I'm not able to find a solution satisfying the needs more than half as good as before.
    The best (because only one) working solution uses disabled items, and they are neither as good to read nor as clearly not editable as the previous way I could use.

    There is no need to conflict with any standard. "Display only" is not necessarily identical to "readonly".
    Besides that, technical reasons should - in my opinion - be defined by real-world-needs and not vice versa.
    Please pardon me, if I didn't catch the point ... but I think I still don't have a solution.

    Regards,
    Ingo
  • 8. Re: Workaround for Session state protection error on readonly fields needed
    Arie Geller Guru
    Currently Being Moderated
    Hello Ingo,

    >> Im just afraid, it doesn't help me with the problem described in my initial post.

    Well, you are right about that. But now, after we established the correct behavior of the APEX engine (i.e. this is not a bug that will be fixed) we can try to find a solution to your problem.

    >> I need these items to be presented in a way, so that they are good to read and clearly NOT editable.

    Your situation and needs are a bit tricky. On one hand, you want to be able to set the value of a Display Only item by using JavaScript (AJAX); on the other, you want to prevent the user from doing the same thing directly on screen. Furthermore, you expect the APEX engine to "know" when the change is legitimate, and when it's not. As the APEX engine can't do that, we already established that it will not allow you to change the value of a Display Only item, and then submit it. We should also bear in mind that everything rendered on page can be changed through DOM manipulation, so if we want to insure that certain items will not be changed on the client side, we should not render them on page.

    It seems that in order to provide the functionality you are asking for, we need to maintain two different sets of items – one for display only purposes, which will not be submitted, and one that will be available to after submit manipulation.

    The first type can easily be achieved by using the Display Only type, with the Save Session State set to No. The APEX engine renders such an item as a text node, and you'll be able to manipulate it using the innerText tag. For example, given the item P1_ITEM1, we can use P1_ITEM1_DISPLAY as the Display Only item, and set its value, using JavaScript, as the following:
    $x('P1_ITEM1_DISPLAY').innerText = 'Hello World';
    The second type is a bit more complicated, and it comes with a price. The APEX engine allows us to define page items that can be used on the server side (manipulated by PL/SQL code) but not be rendered on page. This means that these items will not be accessible to JavaScript, and will not be submitted, hence, they can't be changed on the client side. However, as these items are not submitted, they will not be available to the built-in Automatic Row Processing (DML) process. The price of using this technique is that you need to handle your DML actions manually.

    The trick is to define a regular Text Field, with a condition of Never. The APEX engine will not render the item on page (according to its condition) but will define it as a PL/SQL variable, which can be accessed using the bind variable notation. For example, in your On-Demand PL/SQL process, you can have something like:
    :P1_ITEM1 := l_item1;
    where l_item1 is a PL/SQL local variable, which can be, for example, a result of a SELECT statement.

    With this technique, you are directly setting the value(s) of your "Never" rendered item(s) as part of the AJAX server side process, and you can return the same value(s) to the client, in order to set the corresponding Display Only item(s).

    >> Besides that, technical reasons should - in my opinion - be defined by real-world-needs and not vice versa.

    This is exactly the case. I'm not familiar with your real-world, but in mine, hackers and malicious users are real threat and everyday risk we need to tackle. With APEX 3.x, you didn't have out-of-the-box solution to force read-only condition. As the item was rendered on page, and then submitted, its value could have been tampered with by easy URL manipulation. With 4.x, the APEX engine guard the value for you. For me, this is a real-world solution ( and out-of-the-box).

    With your specific scenario, the implementation is, indeed, much more complicated than what you could have done with APEX 3.x, especially given the need to use manual DML statements. Still, I believe that this is the right and secure way of doing what you are asking for.

    Regards,
    Arie.

    -------------------------------------------------------
    ♦ Please remember to mark appropriate posts as correct/helpful. For the long run, it will benefit us all.

    ♦ Author of Oracle Application Express 3.2 – The Essentials and More
  • 9. Re: Workaround for Session state protection error on readonly fields needed
    ingofa Newbie
    Currently Being Moderated
    Hello Arie,

    thank you once more very much for your comprehensive answer.
    Now I think there are even more aspects, that should be covered by my reply but in this moment, I'm not able to ...

    But in short:
    I suppose I have been too specific in what i need, my question was too technical, and that's why we're in so much detail now.
    I'll try it in another way - maybe there is another, complete different, more practical solution.

    I've got a "teaching database development" environment, where I chose to use APEX and that's why I'm quite limited with respect to time, complexity and tricky efforts - we're nearly tied to using APEX' "declarative programming features" and omit details where possible.

    AFAIK, in APEX there is no way of having a LOV returning multiple values into multiple items (which was very easy in Oracle Forms).
    But in fact, that's what is needed day in, day out. So luckily Patrick pointed me to the AJAX/On-Demand-Process Solution, triggered by the change of the LOV-based Item. This used to be a practical, quite simple and generic soluion, even more with APEX' JSON API-functions.

    Now there are two use-cases - first: all items filled by AJAX process are intended to be edited and written back to a table => no problem.
    Second: some of the items are "just needed clientside", e.g. for information or some checks, NOT to be written back => problems now.
    Example: when I choose a "product" to be in an "order entry", I want to see information like "quantity available", "description" and so on.
    And I want this information to appear additionally, along with the product's reference information and shown in a way that it's clear, it cannot be changed. The "quantity available"-information needs to be available to simple checks on the client-side in a generic way (DOM access tends to be browser specific).

    So, in fact, "saving the session state" is neither neccessary nor actually possible, because that informational items are not even tied to a database column. But how can I implement simple item.value-based checks in another way?

    Maybe APEX4 has some new functionality to achieve that, but that's what I don't know.

    If I have to stay with the AJAX/on-demand-process, the solution you provided would not fit my scenario, sadly.
    I'd rather use the ugly disabled items.

    ---

    And there's one thing I have to get back to once more, concerning session state protection.
    I still cannot believe that, If I, the developer, of sound mind and disposing memory, decide to turn session state protection OFF, APEX has the
    right to defy my order.

    I completely agree with your arguments about risks and threats, but when I to my best knowledge decide to omit one security feature (and this is possible), then I'd like to be heard.

    Regards (and many thanks, again), Ingo
  • 10. Re: Workaround for Session state protection error on readonly fields needed
    Arie Geller Guru
    Currently Being Moderated
    Hello Ingo,

    >> So, in fact, "saving the session state" is neither neccessary nor actually possible, because that informational items are not even tied to a database column. But how can I implement simple item.value-based checks in another way?

    If you don't need to submit the item (save session state) you can use the Display Only item with Save Session State set to No. This will clearly render the information on your page, without allowing any data tampering.

    If you want to manipulate a Display Only item – set or retrieve its value – you can use the built-in (and documented) APEX JavaScript APIs *$s()* and *$v()* . These functions are compatible cross-browsers.

    http://docs.oracle.com/cd/E37097_01/doc/doc.42/e35127/javascript_api.htm#autoId4

    Is this a valid solution to your problem?

    Regards,
    Arie.
    -------------------------------------------------------
    ♦ Please remember to mark appropriate posts as correct/helpful. For the long run, it will benefit us all.

    ♦ Author of Oracle Application Express 3.2 – The Essentials and More
  • 11. Re: Workaround for Session state protection error on readonly fields needed
    ingofa Newbie
    Currently Being Moderated
    Hello Arie,
    that's great. I already tried using the JS-API, but incorrectly assumed equality between $v and $x.value for reading and $s and $x.value for setting the value, which is completely wrong in this specific case.

    So, that is exactly what I need.

    Thank you very very much!

    Ingo
  • 12. Re: Workaround for Session state protection error on readonly fields needed
    Arie Geller Guru
    Currently Being Moderated
    You are welcome.

    Arie.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points