Create a user access history page

[MCatherine1994]

Describe the task Create a new user access history page

Acceptance Criteria

• [ ] Create the route for the new page, add security check (require auth, require application is selected, require user is selected, require application admin role ...)
• [ ] Add the user information card, adjust the style if needs
• [ ] Add the table with the columns
• [ ] Follow the figma design

Additional context

• Epic story 1 #1534
• For now, we do not need pagination

[ianliuwk1019]

As discussed, we might like to do the SideNav change at this ticket or separate it into another ticket:

[craigyu]

To accommodate the url requirement (/users/:userId/applications/:appId), changes have to be made to the frontend router setup. There are two ways of doing this, using createWebHistory or createWebHashHistory. The hash history is the easiest to convert to without doing any extra configuration to the front-end server. It is not SEO friendly, but for an app like FAM, it does not matter. Here is a detailed comparison between the two methods.

1. createWebHistory (History API)

Advantages:

• Clean URLs: URLs do not contain the # symbol, making them cleaner and more readable (e.g., http://example.com/user-details/users/14/applications/11).
• SEO-Friendly: Search engines generally prefer clean URLs, which can improve SEO performance.
• Browser Behavior: Works naturally with the browser’s back and forward buttons, and the history API allows for more advanced control over the browser’s history stack.

Disadvantages:

• Requires Server Configuration: For deep links to work correctly (especially on page refreshes), your server must be configured to redirect all routes to index.html. If this isn’t configured, users may encounter 404 errors.
• Compatibility: Older browsers may not support the history API (although this is less of an issue today).

Best For:

• Applications where clean URLs are important, such as public-facing websites where SEO is a concern.
• Environments where you have control over the server configuration and can set up proper fallback handling for deep links.

2. createWebHashHistory (Hash Mode)

Advantages:

• No Server Configuration Required: Since the routing happens entirely on the client side (everything after the # is not sent to the server), no special server configuration is needed.
• Works Everywhere: Compatible with all browsers, including older ones.
• No 404 Errors on Refresh: Since the server is not involved in handling the routing, you won’t encounter 404 errors on page refreshes.

Disadvantages:

• Ugly URLs: URLs contain a # symbol (e.g., http://example.com/#/user-details/users/14/applications/11), which can look less professional or polished.
• Not SEO-Friendly: Search engines generally ignore the hash part of the URL, so these URLs are less SEO-friendly.
• Less Natural: The use of the # symbol is generally associated with fragment identifiers (anchors) rather than navigation, which might feel less intuitive to some users.

Best For:

• Internal applications where SEO is not a concern, and you need a quick setup without worrying about server configuration.
• Scenarios where you want maximum compatibility with minimal effort, especially in environments where you cannot control server configuration.

Which One is Better for Deep Links?

If SEO and Clean URLs Are Important:

• createWebHistory is the better option. It provides a professional, SEO-friendly approach with clean URLs. However, it requires proper server configuration to handle deep links correctly.

If You Want Simplicity and Compatibility:

• createWebHashHistory is simpler to implement, with no need for server configuration. It’s more foolproof in environments where server configuration might be complex or out of your control, but the URLs are less clean and not as SEO-friendly.

Conclusion:

For a public-facing site or where you control the server and need clean, SEO-friendly URLs, createWebHistory is the way to go. For internal apps or simpler setups where you need to avoid server configuration hassles, createWebHashHistory is a reliable, quick solution.