Creating and running an app with the AppWizard: error?

[ubacher]

If I use the AppWizard to create an app and I then try running the app in chrome it gives an authorization error.
Is this a bug or am I doing something wrong?

(PS: I have written a few apps before w/o this problem. I just discovered this as I tried to write up some instructions for others.)

[Mario]

What is an 'authorization error'?
Does IMatch return an error from an endpoint call because your app has not called /authenticate yet?
Does the browser report an authorization error?
...

[ubacher]

This is when running the Appwizard generated index.html except for one
console.log('Hello world') statement added.

Error from chrome debugger shown in screenshot.

[Mario]

The auth_token your app sends is empty.
It should contain the instance id of the app panel window that is associated with the app.

Do you try to run an app in an external browser (not debugging the app running in the app panel)?
In that case you may not have yet opened an app panel. And hence IMatch cannot associate your external app with an app panel and no instance id is available. Hence, no authentication possible

All access to IMWS must be authenticated with a valid auth_token. And this auth_token is in case of apps running in an app panel the instance if of the panel. IMatch makes this is available via a special function that  is "injected" into the embedded Chromium browser.  And imatchlib.js uses this instanceId to initialize the auth_token.
Usually this is fully automatic and you don't need to care for this when you use IMatch (you have to authenticate with a user and password always when you use IMWS).

My guess is you have not opened an App Panel and you are trying to launch an external app in your browser. Try to open an app panel first. Or restart IMatch and make sure an app panel is open before you open your app in your external browser.

[ubacher]

Mario: I am running the app which you provide as the starting app - i.e. the app generated by the AppWizard!
I assume it should run without error.

[Mario]

Do you run it in an app panel?

[ubacher]

The error only shows when running in chrome.

[Mario]

The /info request you show in your example shows both an instanceid and an auth_token parameter. Where does this come from? /info requires no parameters.
Attach your entire script.

[ubacher]

The /info request you show in your example shows both an instanceid and an ........

It is not my example! It is your example.
Do see the code just run the AppWizard.
Then run the generated code in Chrome.

[Mario]

The default app generated by the app wizard calls AppInfo to get information about "itself".
When you run this app in Chrome it cannot work, because outside of IMatch, no instance id is available (because the app does not run in an App Panel and thus has no instance id).
Remove the AppInfo call if you want to run this in Chrome.

[ubacher]

I start to get the picture.

This is important to know when scripting/debugging.
Are there other calls which will not work when run in Chrome i.e. which can not be debugged in CHrome?

[Mario]

You have no automatic auth-token, you have no automatic URL etc.  Important for web sockets.
The sample apps show how to deal with that.
See the imatchlib.js and imws.js documentation.

You can always enable the remote debugging and instead of launching your app in Chrome or FF or Edge, you can use Chrome to debug the actual app running in the app panel.

[ubacher]

The sample apps show how to deal with that.

Which app is that?

You can always enable the remote debugging and instead of launching your app in Chrome or FF or Edge, you can use Chrome to debug the actual app running in the app panel.

How? Are there instructions somewhere? What port number do I specify in Preferences? Will F12 then work in the app window to open the debugger?

[Mario]

See the Google tutorial on remote debugging.  There are about 1000 other tutorials out there, written or on YouTube.
You can use any free port. For example, add 1 to the default port used by IMatch and then open localhost in your browser for that port:



This will show you all apps running in IMatch currently. Click on the name of the app you want to debug (the names come from the <title> tag in your app index.html).

[ubacher]

There may be 1000 tutorials out there but none about debugging Imatch scripts!

Do I understand this correctly:
If I run the app from port 50520 (the port set up for debugging) then the authorization required has been taken care of
(or is not needed)
while when I run by opening the chrome browser via the icon in the app panel some calls requiring authorization won't work.

Would I then not always run/debug  via the debugging port? (Since I don't know which calls require authorization? Is it the IMWS calls?)

Will this work with modal apps?

[Mario]

Authentication is taken care of because the app runs not in Chrome but in the App Panel.
You can also connect to modal apps that way.
This is not IMatch specific, just normal Chrome/Chromium remote debugging.

Running an app outside IMatch is just a courtesy, because it makes developing apps sometimes quicker. Authentication etc. usually just work, if you hard-code the URL / web socket URL in your script for that purpose. Like all the sample apps do. But an external browser like FF or Chrome don't have access to some of the methods I have "added" to the Chromium browser running inside IMatch. If you want to develop your app in an external browser and you happen to use a method that relies on a Chrome extension you will have to found a work-around.

Or use the App Panel to test your app and Chrome as a remote debugger.
I doubt that many users will ever use a function that requires this - the GetAppInfo function excluded, which of course annot work in Chrome.

[ubacher]

Now I am completely at a loss.  I list my questions here:

What does it mean running an app outside Imatch?

.....because the app runs not in Chrome but in the App Panel.

I thought the app panel is chrome.

What do you mean by remote debugging?

If you want to develop your app in an external browser and ........

There is no other way to use a debugger than to run from a browser - is there? VS Code has some debugging facilities - can we use it to debug an app?

Or use the App Panel to test your app and Chrome as a remote debugger.

Please explain - how do I proceed / recommended way to proceed.


Do I understand the following correctly:

The apps run in a browser. When I select an app to run, Imatch will open a (chrome based) browser window and load the index.html into the browser.
This starts the app. The app interacts with Imatch thru a web server provided by Imatch. (Except that console output is routed from the app/browser to the OUTPUT panel.)
Are there (in effect) two servers - one normal and one for debugging?

When I run an app in an external browser I request the server at

Code Select Expand

http://127.0.0.1:50519/user/my-app/index.html

or I call up:

Code Select Expand

http://localhost:50520/ (Note for others: I set up 50520 as debugger port in Imatch preferences.)
in which case the Imatch server gives me a choice of apps I can run. When I try this it only lists the app manager. Haven't
been able to get at an index.html file to run. ?

Authentication: when is it required? Only when the browser is located on a different host? Do I as a IM2017 only user ever have to worry about authentication?

Sorry about all these questions - seems the more I learn the more questions pop up.

[Mario]

IMatch embeds Chromium, which is also the basis for Chrome.
But IMatch can "add" functions and properties to the embedded browser. Which I used for strings like instanceId and Url. This way IMatch can communicate the instance id of the App Panel in which the App runs and the URL of the IMWS in IMatch to Apps.

These extensions are of course not available in an external browser, Chrome, FF or whatever. This works only for apps running in an App panel (or modal).

What do you mean by remote debugging?

Doing what I explained above. Using Chrome to "connect" to the app running in the App Panel.
Chrome has a feature which allows it to connect to another Chromium-based browser and to debug it. See my explanation above.
Set the debug port, open the URL in you Chrome browser and then click on the name of the app you want to debug (all apps currently running are shown in the list). Becomes clear immediately.

[thrinn]

http://localhost:50520/
(Note for others: I set up 50520 as debugger port in Imatch preferences.)
in which case the Imatch server gives me a choice of apps I can run. When I try this it only lists the app manager. Haven't
been able to get at an index.html file to run. ?

Mario explained it, but just to put it another way:
If you use the URL above to debug your app you don't run your app from the external chrome browser. You merely connect to an already running app from outside. The app you want to debug must be already running in one of the available app panels.

[ubacher]

Thank you thrinn for your explanation which added the missing detail.

Now,of course, another followup question:

Why would I not always use the "debug browser" instead of an external browser. One answer I can think of is
that it requires me to have a chrome browser available - since it does not work with other browsers.
Any other reasons?  (Keep in mind: I am only an IM2017 scripter.)

[thrinn]

I can not really answer that. I have no use case where I reallyneed to develop an App outside of IMatch. Might be different regarding Apps that are intended to be run in IMatch Anywhere, though. But at the moment I do not want to be bothered with authentication or other additional problems...

At the moment I always use this setup as "development environment":
- Visual Studio Code as editor
- App Panel 1 open with the WebServices Documentation.
- App Panel 2 open (detached, on my second monitor) running the App I (try to) develop
- External chrome browser connected to the remote debugging port. localhost:50520 set as bookmark for quick access to the debugging entry point where all running apps are listed.

So far this works well for me.

[sinus]

Ahh, for a non-programmer this whole JS-stuff is really really very complicated.
At least is sounds as it is difficult.

Thorsten, your 4 steps for your setup, I understand.
One question, I work ONLY with IMatch2017 (at the moment still testing, I can not use it in my daily work ONLY because the scripting stuff), not with a browser, I work only with:

- Notepad++ as my editor (Visual Studio Code is at the moment too complicated for me, JS alone is enough  )
- App Panel 1 open with my App, what I am trying to do
- App Panel 2 open for lookin in other stuff like the examples from Mario

Finally I must not "fiddle" round with chrome and so on, it is not a must?

[thrinn]

Finally I must not "fiddle" round with chrome and so on, it is not a must?

You don't need Chrome to develop your App. But it is very helpful for debugging. Maybe it is easier to understand if you look at Chrome in this context only as an debugger window. In the old BASIC IDE, there where also some, well, basic debugging facilities like setting a breakpoint, singel-stepping through your code, and inspecting the content of some variables. Chrome offers all this (and a much more) in a much more sophisticated way.

I admit the chrome debugging tools look a bit overwhelming at first, but for a start you will only need a small part of the funtionality (just like in IMatch ).
For example, what I use at the moment is:

• Set breakpoints to stop my App at some lines in code.
• Inspect the contents of variables.

Often what an endpoint returns is deeply nested (e.g. response object containing a data array, each entry in this array representing the info for one file, each file info another array with different properties...), therefore it is cumbersome to "debug" only using console.log.

And there is near to nothing to setup for using chrome as debugger: Just configure the remote debugging port in IMatch (once!), the bookmark localhost:<debugging port> in chrome, done!

[Mario]

Finally I must not "fiddle" round with chrome and so on, it is not a must?

No.

But running your app in Chrome (either directly by opening the app URL or using remote debugging) has many benefits during development. The console is better. You can set break points to halt execution of your app, see variable contents, steo through your app to see what is is doing.

Except for some very specific cases, the code and wrappers I have written (imatchlib.js and imwslib.js) allows you to run your app in Chrome (or another browser like FF) as well as in App Panels. I did this to speed up developand make it easier. I always develop my apps "in" Chrome because of the built-in developer tools.

For example, the Net tab in chrome shows you the requests your app is sending to IMatch (with all parameters and payload) and the responses from IMatch. In the Preview tab in the Net tab Chrome automatically formats the JSON data returned by IMatch to make ti easily readable for humans.

This is how you quickly understand "When I call the /categories endpoint for a file, what does IMatch return"?
This is how it looks when I work on an app (in this case, the Category Dashboard). I open the app via it's URL in Chrome, press <F12> to open the developer tools and I'm good to go.
In this example I'm using the Network tab to see the data IMatch is returning.

(Click to see full size)



You can see all requests the browser has done (to load the HTML, CSS and JavaScript files etc.) Then you click on the endpoint call and Chrome shows you everything about it.
You cannot understand JSON responses without seeing it this way.
The response contains data for one file.The file has 4 categories. For each category the requested fields (id, path, name etc.) are shown.

[sinus]

Hi Thorsten and Mario

Thanks you both for your very good explanations. Since your both answers say (more or less) the same, you both must be right. 

I will look at it and try to use chrome as a debugger.
Well, the time will come, when my first real usable script will run ... I hope. 

Thanks, I appreciate this very much!