| Key: |
SHALE-362
|
| Type: |
Bug
|
| Status: |
Resolved
|
| Resolution: |
Fixed
|
| Priority: |
Major
|
| Assignee: |
Unassigned
|
| Reporter: |
Craig McClanahan
|
| Votes: |
0
|
| Watchers: |
0
|
|
If you were logged in you would be able to see more operations.
|
|
|
|
The current "out of the box" security of Shale Remoting is better (in 1.0.4-SNAPSHOT) than it was in 1.0.3, but still needs to be improved:
* "Dynamic" processor should exclude by default all managed bean
names that are implicitly defined in the JSF spec, and have public
zero-args methods that might mess things up. (Example: executing
#{applicationScope.clear} would be bad.
* All processors should be enhanced to *always* obey their default
exclude lists, even if the user specifies additional exclude patterns.
|
|
Description
|
The current "out of the box" security of Shale Remoting is better (in 1.0.4-SNAPSHOT) than it was in 1.0.3, but still needs to be improved:
* "Dynamic" processor should exclude by default all managed bean
names that are implicitly defined in the JSF spec, and have public
zero-args methods that might mess things up. (Example: executing
#{applicationScope.clear} would be bad.
* All processors should be enhanced to *always* obey their default
exclude lists, even if the user specifies additional exclude patterns.
|
Show » |
|
Improve default security of Shale Remoting
SHALE-344).