Got it! So you've opened issue OFBIZ-13231 and linked it to PR 889 as the fix. Thanks for working on this!
Arifa Hashmi On Mon, 5 May 2025 at 18:29, Nicolas Malin <nicolas.ma...@nereide.fr> wrote: > I opened issue OFBIZ-13231 [1] and like it to PR 889 [2] to fix it. > > Nicolas > > [1] https://issues.apache.org/jira/browse/OFBIZ-13231 > [2] https://github.com/apache/ofbiz-framework/pull/889 > > > Le 05/05/2025 à 11:44, Nicolas Malin a écrit : > > Thanks Arifa for your return and confirm the case :) > > > > I started a fix based on solution two. > > > > I'll publish it on jira on the days ! > > > > Nicolas > > > > Le 03/05/2025 à 05:31, Arifa Hashmi a écrit : > >> It looks like you've encountered a complex issue with OFBiz's AJAX call > >> handling, specifically how the `*SetTimeZoneFromBrowser*` request is > >> failing due to URL pattern mismatches, leading to a *405 error* . > >> > >> *Issue Breakdown * > >> - The request `*SetTimeZoneFromBrowser*` is defined in ` > >> *common-controller.xml*`, making it globally available. > >> - JavaScript attempts to execute it via a *relative URL*, causing > >> inconsistencies when combined with REST-style URLs. > >> - The `*ControlServlet*` fails to recognize the request format, > >> leading to > >> the 405 error . > >> > >> *Proposed Solution* > >> - Instead of using relative calls, '*a dedicated webapp*' > >> (`common-js`) is > >> suggested for handling these requests, ensuring proper routing. > >> - The webapp would act as a relay, avoiding exposure of > >> `framework/common` > >> and separating theming from functional requests. > >> - Example fix: > >> ```js > >> $.ajax({ > >> url: "/common-js/control/SetTimeZoneFromBrowser", > >> type: "POST", > >> async: false, > >> }); > >> ``` > >> -------------------------------------------------------------- > >> > >> > >> Implementing a *switch-case structure* can help manage different AJAX > >> requests effectively, but it needs additional adjustments to fully > >> resolve > >> the '405 error issue' you described in Apache OFBiz. Below is a 'full > >> implementation strategy' that addresses the problem while ensuring > >> security > >> and proper request routing. > >> > >> --- > >> > >> Suggest Solution: Using a Dedicated WebApp with Dynamic Routing > >> > >> Since the issue arises due to 'incorrect request routing in REST-style > >> URLs', we will: > >> 1. Use a dedicated web app (`commonext`) to handle such AJAX requests. > >> 2. Implement a switch-case structure in JavaScript to dynamically > >> adjust > >> request URLs. > >> 3. Ensure security by managing authentication separately for the web > >> app. > >> > >> --- > >> > >> Step-by-Step Implementation > >> > >> 1. Configure the Dedicated WebApp (`commonext`) > >> Modify `webapp.xml` to set up a new web app that will act as a relay for > >> common requests. > >> > >> ------------------------ xml > >> > >> > >> *<web-app name="commonext" location="commonext" app-bar-display="true"> > >> <security security-constraint="true"/></web-app>* > >> ------------------------ > >> > >> 2. Define Request Handlers in `commonext-controller.xml` > >> Create handler mappings in `commonext-controller.xml` to process > >> requests > >> properly. > >> > >> > >> > >> > >> > >> > >> > >> *---------------------------xml<request-map > >> uri="SetTimeZoneFromBrowser"> > >> <security https-required="true" auth-required="false"/> <event > >> type="service" name="setTimeZoneService" > >> invoke="org.ofbiz.common.SetTimeZone"/> <response name="json" > >> type="json"/></request-map>----------------------------* > >> > >> 3. Update the JavaScript AJAX Calls > >> Modify the AJAX call in JavaScript to ensure requests are directed > >> through > >> `commonext`. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> *------------------------ jsfunction getRequestUrl(requestType) { > >> switch > >> (requestType) { case "timezone": return > >> "/commonext/control/SetTimeZoneFromBrowser"; case "inventory": > >> return "/commonext/control/GetStockDetails"; case "order": > >> return "/commonext/control/FetchOrderStatus"; default: > >> return "/commonext/control/DefaultHandler"; }}* > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> *$.ajax({ url: getRequestUrl("timezone"), type: "POST", async: > >> false, success: function(response) { console.log("Request > >> successful!", response); }, error: function(error) { > >> console.log("Error in request!", error); }});* > >> ----------------------------------- > >> > >> 4. Address Authentication Issue > >> Since separate web apps maintain independent sessions, use token-based > >> authentication or a cookie-based method. > >> > >> - Option 1: SSO (Single Sign-On) > >> - Implement an OAuth-based authentication system . > >> - Users authenticate once, and tokens are passed across multiple > >> web apps. > >> > >> - Option 2: Secure Cookie-Based Authentication > >> - Generate a security token upon login. > >> - Store the token in a HTTP-only, secure cookie . > >> - Validate the token before processing requests in `commonext`. > >> > >> --- > >> > >> ### *Expected Results * > >>>> AJAX requests will no longer fail due to incorrect REST-style URL > >> handling. > >>>> Requests will be correctly routed via `commonext`, resolving the > >>>> '405 > >> error'. > >>>> Authentication is properly handled without exposing core framework > >> security. > >> > >> This approach provides a 'scalable and maintainable solution' for > >> handling > >> common OFBiz AJAX requests while ensuring security compliance. > >> with regards > >> Arifa Hashmi > >> > >> On Fri, 2 May 2025 at 13:39, Nicolas Malin<nicolas.ma...@nereide.fr> > >> wrote: > >> > >>> Hi all, > >>> > >>> I'm in front of a particular issue where the fix isn't really easy and > >>> need to share :) . > >>> > >>> I detected a problem with some ajax call did by js script that failed > >>> with error 405 like : > >>> > >>> > https://demo-next.ofbiz.apache.org/webtools/control/entity/find/SetTimeZoneFromBrowser > >>> > >>> > >>> To reproduce just display the page > >>> https://demo-next.ofbiz.apache.org/webtools/control/entity/find/Party > >>> and analyze network traffic. > >>> > >>> Ok the reason : > >>> > >>> SetTimeZoneFromBrowser is a request define in common-controller.xml, so > >>> available on all component. In js the call is realize by : > >>> ```js > >>> $.ajax({ > >>> url: "SetTimeZoneFromBrowser", > >>> type: "POST", > >>> async: false,... > >>> ``` > >>> So the navigator use the relative url to execute the call. In general > >>> case we have a page like > >>> https://demo-next.ofbiz.apache.org/$component/control/$request so js > >>> script realized their call with > >>> https://demo-next.ofbiz.apache.org/$component/control/$request-js . > >>> Like > >>> each request-js are present on common-controller.xml all component that > >>> include it can response. > >>> > >>> With rest url, the uri pattern is more complex and the script js that > >>> generate a relative call like we have upper : > >>> > >>> > https://demo-next.ofbiz.apache.org/webtools/control/entity/find/SetTimeZoneFromBrowse > >>> > >>> . > >>> The ControlServlet behind failed to retrieve the correct request and > >>> generate a http error 405 > >>> > >>> > >>> How to fix : > >>> After different tries, I propose to remove all relative call and create > >>> a dedicate webapp for that. > >>> ```js > >>> $.ajax({ > >>> url: "/common-js/control/SetTimeZoneFromBrowser", > >>> type: "POST", > >>> async: false,... > >>> ``` > >>> Open a new webapp on commonext to do that and redirect all relative > >>> call > >>> to it. > >>> I propose to implement it on commonext because framework/common need to > >>> keep without exposure. Common-theme is dedicate expose theming > >>> information and not a direct relay to common request. So commonext > >>> seems > >>> to be the better solution to be a relay for common request manage by > >>> the > >>> common-controller. > >>> > >>> The problem with this solution, all webapp are their session separate, > >>> so access to a json request through commonext generate an security > >>> issue > >>> if the request have auth enable. We can enable the sso on ofbiz for > >>> that > >>> but do we need that for all OFBiz webapp by defaut. We can imagine a > >>> spotted solution to use cookies system like autologin with more > >>> security, only on commonext to be sure to allow the functionality on > >>> many configuration. > >>> > >>> Thanks to take this read time and if you have any sharing on it to > >>> found > >>> the better solution. > >>> > >>> Nicolas > >>> > > >