Difference between revisions of "AppSuite:Debugging production servers"

(Described the new proxy feature of grunt dev)
(Replaced content with "The content on this page has moved to https://documentation.open-xchange.com/latest/ui/miscellaneous/debugging-prodserver.html Note: Open-Xchange is in the process of mig...")
 
(4 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{Stability-experimental}}
+
The content on this page has moved to https://documentation.open-xchange.com/latest/ui/miscellaneous/debugging-prodserver.html
<div class="title">Debugging production servers</div>
 
  
A how-to for debugging your local UI plugin in combination with production and staging servers, which use redirects, HTTPS, and other things which break with the auto-generated Grunt configuration.
+
Note: Open-Xchange is in the process of migrating all its technical documentation to a new and improved documentation system (documentation.open-xchange.com). Please note as the migration takes place more information will be available on the new system and less on this system. Thank you for your understanding during this period of transition.
 
 
== Introduction ==
 
 
 
Not everybody has access to a dedicated test server. Sometimes, a plugin requires a backend system which is hard to access outside of existing infrastructure. And sometimes, a bug appears only on a production server. There are many reasons why a server which is used by <tt>grunt dev</tt> can not be reconfigured and has to be used as-is.
 
 
 
The most frequent reason, why debugging with a remote server fails, is a redirect to an external login page. After the login, the browser is usually redirected to the original domain, and all the cookies used for authentication are also set for that domain, not http://localhost:8337, where Grunt listens.
 
 
 
The solution is to use grunt as an HTTP proxy server, which intercepts all requests to the server's domain.
 
 
 
In this article, <tt>''example.com''</tt> is user for the server domain, which you should replace by the real domain of the OX server.
 
 
 
== Configuring Grunt ==
 
 
 
Following is an example <tt>grunt/local.conf.json</tt> file:
 
 
 
{
 
    "proxy": true,
 
    "appserver": {
 
        "protocol": "https",
 
        "livereload": false,
 
        "server": "https://''example.com''/''custom-path''/",
 
        "path": "/''custom-path''/",
 
        "rejectUnauthorized": false,
 
        "verbose": [],
 
        "prefixes": [
 
            "build/",
 
            "../../web/ui/build"
 
        ],
 
        "manifests": [
 
            "build/manifests/",
 
            "../../web/ui/build/manifests"
 
        ]
 
    },
 
    "debug": true,
 
    "coreDir": "../../web/ui/build"
 
}
 
 
 
The relevant settings are:
 
 
 
;<tt>"proxy": true</tt>
 
: instructs Grunt to start an HTTP proxy on port 8080. Note that the value is outside the <tt>"appserver"</tt> section.
 
;<tt>"protocol": "https"</tt>
 
: to use HTTPS on port 8337.
 
;<tt>"livereload": false</tt>
 
: because LiveReload can't be proxied.
 
;<tt>"path": "/''custom-path''/"</tt>
 
: must correspond to the path in the <tt>"server"</tt> entry and can be omitted if it's <tt>"/appsuite/"</tt>.
 
;<tt>"rejectUnauthorized": false</tt>
 
: is helpful with certificate problems, especially for integration tests of the login mechanism on a POC system with self-signed certificates.
 
;<tt>"index": "/"</tt>
 
: If the main path uses an HTTP redirect for a custom login page, then the initial request should not be intercepted by Grunt. Adding this entry in the <tt>"appserver"</tt> section disables the interception. This has two side-effects:
 
:# The main HTML file is always served by the original server, and therefore
 
:# The timestamps used for cache-busting are not updated by Grunt.
 
:Unfortunately, this means clearing the cache will be required more often. If that becomes too much overhead, you can log in, then remove the option and restart Grunt.
 
 
 
After the configuration is complete, Grunt is started like always with
 
 
 
grunt dev
 
 
 
== Launching the browser ==
 
 
 
Now that the proxy is running, you just need to use it when debugging your code in the browser. Most browsers have their own proxy settings, which override system-wide settings. They also respect environment variables like <tt>http_proxy</tt>.
 
 
 
http_proxy=http://localhost:8080 firefox
 
 
 
Chrome does not have its own settings (it starts the global settings dialog) and it ignores http_proxy. Instead, you have to use a command line parameter:
 
 
 
chromium --proxy-server=http://localhost:8080
 

Latest revision as of 09:59, 22 May 2017

The content on this page has moved to https://documentation.open-xchange.com/latest/ui/miscellaneous/debugging-prodserver.html

Note: Open-Xchange is in the process of migrating all its technical documentation to a new and improved documentation system (documentation.open-xchange.com). Please note as the migration takes place more information will be available on the new system and less on this system. Thank you for your understanding during this period of transition.