You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Achieve was first built for use in a beginning programming course. Students worked on localhost and did not have admin privileges to open their system to external clients. The work being done in relation to achieve-proxy has opened this issue for serious consideration. Achieve is sufficiently well developed that it may be considered for "serious" use in production.
Early release of achieve-proxy included opening CORS (preflight - all OPTIONS requests) with * access. Whether this signal is honored depends on access controls in proxy servlets. Maybe even early release should somehow respond so that the preflight signal is honored - i.e. without CORS violation. (Should at least be illustrated in example - customization.)
Current work aims only at controlling access to proxy servlets and CORS is only part of the story. The bigger question is whether ALL access control should be moved from achieve-proxy to achieve. As achieve-proxy aims to allow web apps and proxies in the same server instance, more thought needs to be given to securing the entire system.
Related issue #1 deals with identifying external clients.
The text was updated successfully, but these errors were encountered:
Achieve was first built for use in a beginning programming course. Students worked on localhost and did not have admin privileges to open their system to external clients. The work being done in relation to achieve-proxy has opened this issue for serious consideration. Achieve is sufficiently well developed that it may be considered for "serious" use in production.
Early release of achieve-proxy included opening CORS (preflight - all OPTIONS requests) with * access. Whether this signal is honored depends on access controls in proxy servlets. Maybe even early release should somehow respond so that the preflight signal is honored - i.e. without CORS violation. (Should at least be illustrated in example - customization.)
Current work aims only at controlling access to proxy servlets and CORS is only part of the story. The bigger question is whether ALL access control should be moved from achieve-proxy to achieve. As achieve-proxy aims to allow web apps and proxies in the same server instance, more thought needs to be given to securing the entire system.
Related issue #1 deals with identifying external clients.
The text was updated successfully, but these errors were encountered: