Web Security Framework
Description
How Web Security works.
Web Security Framework - Login Tracking
The web security system has new options for the login activity log. The current text based login activity file has a new output format. The original format included dates in US format and limited information. The new format uses text based dates and includes the IP address of the client computer
Old Format
01/15/2010 10:29:15 62 am - USERID:Sally - LOGIN EXPIRES:01/15/2011 10:29:15 62 am
New Format
127.0.0.1 - 15/January/2010 10:29:15 62 am - USERID: Sally - LOGIN EXPIRES: 15/January/2011 10:29:15 62 am
The login activity data can now be sent to a user defined function. This allows you to easily store login activity in a database. A genie to enter code in the function is available if the option "User defined function" is selected for the "Login activity log save to" option. Specific values are available in the function, including any session variables. These values can be used to save login activity data to a file or table. The activity data can now include failed logins. When enabled, all failed attempts to log in will be recorded in the login activity log. If not checked, only successful logins are recorded in the log file. The activity data can now track logout actions. When enabled, any user logged out by the 'a5ws_logoutuser()' function will be recorded in the login activity log. No log entry will be created if no one is logged on when the log out function is called.
Web Security Framework - Auto-complete on Log-In Page
Some browsers offer a feature to auto-complete certain fields on a webpage. An option named 'Autocomplete Off' has been added to the Login View properties under 'Customize' to add the autocomplete="off" attribute to the element. Checking this option will only suppress the prompt to save login data on most browsers. It will not prevent auto-fill if data has already been saved by the browser for the login.
Web Security Framework - Component Level Security - Reports
When component level security is enforced in the web security system, permissions for reports must be explicitly assigned. A change has been made to allow spaces to be used in the report name, although it is good practice to use underscores in place of spaces. This is particularly true in web applications where a report may open directly from a URL. Browsers don't always deal well with spaces in url's.
Web Security Framework - Verify Files
The web security system now verifies that all files listed in the web security permissions file physically exist in the project. If a file no longer exists in the project, it is automatically removed from the permissions file. The clean up process is applied when security for any page, folder, or component is saved or the Page Security and Component Security genies are opened. A function has been added to run the process manually if desired. You can run this function from the Interactive Window.
a5ws_CleanPageSecurity([C project ])
Virtual page security, component level security, and AJAX requests
Page access security is applied when a page that contains an AJAX enabled grid is initially opened. However, the grid can be refreshed by many requests that do not reload the page, such as column sorts, searches, and submits. The Alpha Anywhere server now automatically applies the page security to any AJAX request that refreshes a grid that is placed directly on a page. Some actions can open an AJAX enabled grid on a virtual page. These include actions that open a grid in a window, row expander, tabbed UI, or page layout component. In this instances, there is no fixed page for the security validation tests and no security is applied to prevent opening the grid. Security is still applied within the grid for hide / show and update actions. Reports opened by an AJAX action also use a virtual page.
This build introduces optional component level access security. The security settings have a new property in the Customize section to Enable component security for 'virtual pages'. Enabling this property will allow setting security on a component in the same way security can be set on a page. When enabled, the default action is to deny access to a grid or report on a virtual page. Grids opened directly on a page are still controlled by the page security. Component security can be set by the right click menu on the component list for grids, and from the Component Security option in the Web Security Menu. The grid can be Always Denied, Always Allowed or Requires Login. This security is applied to any grid or report opened on a virtual page and any AJAX actions from the grid. If this option is not checked, all AJAX calls on virtual pages are always allowed
An additional option is available when component security is enabled. The option Always enforce security at component level for AJAX grids will force a grid opened directly on a page to use the component security in place of the page security. This is more secure than using the page level security as it can't be bypassed by a malicious AJAX call. An additional change now closes any AJAX windows that are were opened by the application if the user is redirected to a page with a login component.
See Also