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
The charge report is not working since moving BTM to ace.jlab.org because the myquery app is unreachable. When the app was on accweb a proxy was created at /myquery to allow the Charge report to query for data (sidestepping same origin restrictions and taking advantage of on-site no-auth). This is problematic on ace.jlab.org because myquery requires auth from offsite.
A working example can be viewed internally on the soon to be decommissioned legacy wildfly2 server.
Solutions:
A. Proxy
One solution is to include an in-app restricted proxy (just the exact myquery requests needed for charge report). A few variants of this exist:
Maintain client-side requests, but update to use proxied endpoint
Perform requests entirely server-side (with long waits) and then write results inside response HTML
An elaborate caching setup in which a daily query to myquery for previous day runs in a scheduled task and caches results in Oracle database
The elaborate in-app caching setup has the nice feature of page load by users is lightning quick, whereas right now the first person to request a given date range must wait for a myquery request that does an integration too (1 year span takes roughly 15 seconds). Also, we're currently relying on a precarious Apache HTTPD caching configuration to keep subsequent requests to myquery snappy. On the con side the precariousness is likely just transferred from the httpd config to the app. For example the automated nightly scheduled task may fail. On each page load the count of number of records (days) would need to be made to check if the span includes all data. If not, the daily updater routine would need to be invoked to crawl the given range to fix any gaps.
B. OAUTH
If we update the httpd forms and httpd sessions auth on epicsweb.jlab.org to use OAuth we could then authenticate to the service using OAuth.
Went with simple request proxy with PV whitelist. Good enough for now, but may want to improve in the future. Appears caching isn't working at the moment. Also, epicsweb.acc.jlab.org is currently hard-coded...
The charge report is not working since moving BTM to ace.jlab.org because the myquery app is unreachable. When the app was on accweb a proxy was created at /myquery to allow the Charge report to query for data (sidestepping same origin restrictions and taking advantage of on-site no-auth). This is problematic on ace.jlab.org because myquery requires auth from offsite.
A working example can be viewed internally on the soon to be decommissioned legacy wildfly2 server.
Solutions:
A. Proxy
One solution is to include an in-app restricted proxy (just the exact myquery requests needed for charge report). A few variants of this exist:
The elaborate in-app caching setup has the nice feature of page load by users is lightning quick, whereas right now the first person to request a given date range must wait for a myquery request that does an integration too (1 year span takes roughly 15 seconds). Also, we're currently relying on a precarious Apache HTTPD caching configuration to keep subsequent requests to myquery snappy. On the con side the precariousness is likely just transferred from the httpd config to the app. For example the automated nightly scheduled task may fail. On each page load the count of number of records (days) would need to be made to check if the span includes all data. If not, the daily updater routine would need to be invoked to crawl the given range to fix any gaps.
B. OAUTH
If we update the httpd forms and httpd sessions auth on epicsweb.jlab.org to use OAuth we could then authenticate to the service using OAuth.
See:
The text was updated successfully, but these errors were encountered: