Skip to Main Content
Feature Request FR-4099
Product Area Developer Experience
Status OPEN

44 Voters

Add option to remove session ID from URLs

philipp hartenfeller Public · Nov 11 2024

Idea Summary
Correct me if I am wrong, but my impression is that adding the session ID to the URL has only a benefit if you use session cloning (open in new tab with an isolated session) to keep track of which session to use. In general, the session cookie is enough to match a request to a session.

From my impression, session cloning is not used often, and I see disadvantages of having the session in the URL:

  • It is not useful in locating a resource.
  • It makes bookmarks, sharing or copying links, etc. complicated because opening a link with a hard-coded session ID will kill your currently active session with a different session ID. Without the session ID in the URL, I would expect opening a link to just re-use the currently active session.
  • It is bad UX: non-technical users will not understand this concept and just think that there is something wrong with the app.
  • It is bad for SEO/Web Crawlers. As someone running public APEX apps, I get massive loads of web crawlers that get a unique URL (thanks to the session ID) on every visit and expect different content. So they try again and again to crawl the page.

I also want to emphasize the point that APEX is super unique in this behavior. I don't know of any other website framework that adds session context to URLs.

Use Case
General User Experience and public-facing apps.

Preferred Solution (Optional)
Switch in Application Attributes next to “Friendly URLs”, which disables session IDs in URLs. It could either disable session cloning or add the session ID to any cloned session.

This idea is open.

Known Duplicates

Known duplicates

FR-4137
FR-4137 Hiding Session Token In URL

Comments

Comments

  • ino.laurensse OP 3 months ago

    You can see on the Community Forum that there is no session id in the URL. But that is actually an ugly hack:

        if (!inPWA()) {
       let orgUrl = new URL(window.location);
       window.addEventListener('DOMContentLoaded', (event) => {
           window.history.replaceState({}, '', `https://forums.oracle.com/ords/apexds/post/session-in-url-causes-problems-in-saved-bookmarks-6474${orgUrl.hash}`);
       });

    You still see the original URL briefly when the page loads.

  • menno.hoogendijk APEX Team OP 13 days ago

    Hi Philipp,

    Did you have a look at Rejoin Sessions?

    https://docs.oracle.com/en/database/oracle/apex/24.2/htmdb/manging-instance-security.html#GUID-C676EF2F-2939-4EC3-9385-8FAEA99C8971

  • philipp hartenfeller OP 11 days ago

    @menno.hoogendijk 

    Hi Menno,
    Yes, this solves part of the issue. But my main point is that having the session ID in the URL is more harmful than helpful. And I think rejoin session will put the session ID back after rejoining, right?

  • menno.hoogendijk APEX Team OP 11 days ago

    You could use Rejoin Sessions only on public pages for public facing apps. I believe it will not put the session ID back as long as you stay on public pages. 

    Having the session ID in the URL is actually not harmful and improves app security as explained in the doc:

    While supporting session joins is convenient, it does present some serious security risks:

    Triggering malicious session state changes or other modifications.

    If an attacker tricks the user into clicking an application link, this can trigger malicious session state changes or other modifications. Because of this risk, APEX requires a checksum that the attacker will not be able to guess when processing requests that alters data.

    Triggering unintended changes between applications.

    If a user has two applications open in separate tabs on the same APEX instance, one application could trigger unintended changes in the other one. The attacking application could be written by a hacker or it could have an XSS vulnerability that enables an attacker to inject code. This application could use Ajax calls that simulate user interactions with the other application.

  • j_schuster OP 11 days ago

    Thanks @menno.hoogendijk for you explanation!

  • philipp hartenfeller OP 11 days ago

    @menno.hoogendijk 

    Thanks for your response! I just tested the “Rejoin Sessions - Enabled for All Sessions” option. I also set “Page Access Protection” and on the item level to unrestricted.

    • It actually does not set the session ID in the URL when no page item is passed via the URL (great! )
    • If you want to set a page item via the URL, it requires the session ID. If I remove the session parameter and reload it will redirect me to the log-in page so actually not rejoin.

    Looks like a bug or am I misunderstanding how it should work? 

    APEX requires a checksum that the attacker will not be able to guess

    Completely agree. But you can pass the checksum without having to pass the session ID. The session secret is still in the cookie.

    For the second paragraph I don't understand what this has to do with having a SID in the URL.

    And I want to again point out that APEX is different from all other web applications I know. Banking websites, social media, etc., of course, also use sessions, but only store the information in the cookie and not additionally in the URL.

  • menno.hoogendijk APEX Team OP 11 days ago

    Not sure why setting an item requires the session ID. This works fine for me:
    https://apex.oracle.com/pls/apex/r/citiest/public-app/home?P1_NEW=test

    Another workaround is to use the x01 and grab that value to populate your page item:
    https://apex.oracle.com/pls/apex/r/citiest/public-app/home?x01=lalalala

    I think the second paragraph is about invoking an Application Process by name for example. The second app is capable of generating valid URLs for the first app because there is no SID.

    I'll forward your questions to the team to check if they can provide more detailed answers.