Type: Technical Documentation
Affects Version/s: None
Component/s: Application Security
Sprint:Iteration 36, Iteration 37, Iteration 38, Iteration 39, Iteration 40, Iteration 41, Iteration 42, Iteration 43, Iteration 44, Iteration 45
Type of Documentation:Deployment
Why does this feature exist?
- Because CORS filtering needs to be SAAS ready.
Who needed it?
- Instance admin
What problem does it solve?
- Previously because there is only system settings for CORS, which means instance can not have its own CORS settings. In a SAAS situation, each instance will be used for different customers, and each customer will need to have the ability to configure its own CORS settings.
How can it be used by the user or developer?
- Developer can this point wont be using it, while the user(instance admin) can figure instance CORS setting in his own instance.
How does it make life easier?
- Not really, probably making the whole system more complex, in exchange for allowing CORS configured at instance level.
What does this feature do? For example, does it let you add/change/delete anything?
- This feature allows instance admin to configure CORS settings at instance level, the way to configure at instance level remains the same as at system level.
How else does it operate on data?
- The new CORS infrastructure will try to match url patterns that are configured at instance level first, then try to match url patterns that are configured at system level, meaning if there are same url patterns, those configured at instance level will take precedence.
Can a developer modify or customize any of these features?
- No, at least not at this point.
List the steps a developer needs to take to implement this feature, or a user needs to perform in order to use this feature.
For instance admin:
- he/she needs to go to control panel -> instance settings -> CORS configuration
- Adding CORS configuration entries the same way as at system level
Note: The term of CORS configuration refer only to PortalCORSConfiguration, but not the WebContextCORSConfiguration, WebContextCORSConfiguration will remain as a system settings.
Key related classes/methods and modules, configuration interfaces; any specific implementation details that helps understanding how it works, provides hints for debugging and fixing.
PortalCORSConfiguration.java : Containing the configuration entries
PathPatternMatcher.java : A data structure with its algorithm, responsible for constructing a mapping from input URL path to matched URL pattern with stored cargos
DynamicPathPatternMatcher.java : One implementation for PathPatternMatcher, allowing virtually unlimited number of URL patterns
StaticPathPatternMatcher.java : One implementation for PathPatternMatcher, only limited number of URL patterns can be store, in exchange for faster pattern matching time.
PortalCORSServletFilter.java : Responsible for handling CORS request, it accepts all requests and filter out non CORS requests, the filtering is made possible by using PathPatternMatcher.
- Each instance will have its own PathPatternMatcher.
- If there is a change to CORS system settings, all instance PathPatternMatchers will be re-constructed. If there is a change to one of the CORS instance settings, this instance PathPatternMatcher will be re-constructed.