Application Deployment Issue in Beta2

[RobertScheitlin__GISP]

Moxie Zhang‌

There seems to be an issue in Beta 2 in the env.js when you build an app and choose download and deploy the app on your web server. If you do not manually set your apiUrl in the env.js then it goes down a function path to attempt to get the portal url and it fails severely and results in a apiUrl of  "http://gislap183/jsapi/jsapi/". This is due to the fact that the getPortalUrlFromLocation function is returning "http://gislap183/http://gislap183//" on my machine. Is there something that I have missed in the docs about environment setup or is this a bug in Beta2?

[ZhifangWang1 · Accepted solution]

You don't have to edit the env.js of created app, by default the created app using the js api comes with your portal.

However, there is one thing important. When you first open WAB on your machine, it asks you to log into Portal, for instance, you logged into Portal: http://abc.com, then WAB will automatically create an item and register the item with an app id an return url for using for OAuth2, this is documented on the WAB's setportalurl page. Notice that, the auto created item in your Portal, whose return url is the same with your webserver's name which your WAB runs on, for this instance, the return url of the item is also http://abc.com.

So you can now only deploy your app on http://abc.com. If you deploy your app created on http://abc.com'sWAB to http://def.com, it does have a problem. This is because the http://def.com url is not registered as the return url of your Portal's item. The solution is to add http://def.com as the return url into the Portal's item (which is automatically created by WAB).

[RobertScheitlin__GISP]

Wang,

   The issue with that workflow is that I (and I expect many others) use web app builder on a development machine and when it asks for the portal account I just used my organizational account, and then when I have the app all configured the way I want I move it to my production web server.

[ZhifangWang1]

Robert,

If your deployed app' resources are all public, I think it's fine with this workflow and does not require any edits to the app to make it work on your server.

However, if there's some resources that requires authentication, or that's not shared to public, then OAuth2 authentication will occurs in your deployed app. This depends.

1. If you deploy the download app to the same machine which Web AppBuilder runs on, the app will woks fine, you don't need to do additional work.
2. If you run Web AppBuilder on machine A (your development machine) and logged into Portal on machine A, and then want to deploy the app (which has private resource in Portal on machine A) on machine B, what you have to do is my answer above: add machine B's FQDN to the redirect uri list in the item's App Info which is created automatically by WAB in your Portal on machine A.
3. If you run WAB on machine A and logged into Portal on machine B (your server), and then want to deploy the app which has private resource in Portal on machine B, what you have to do is to add machine B's FQDN to the redirect uri list in the item's App Info which is created automatically by WAB in your Portal on machine B.

For your workflow, I think it's same as situation 2. You run WAB on machine A and logged into Portal runs on machine A, made an app has private resources on machine A and want to deploy it to machine B, is this right?

Hope I have made it clear for you. If you have still any questions, please let me know.

[GrantMullins]

I don't see any items being added into my Portal from WAB.  Is there some documentation on how that works?

[GrantMullins]

Also suffering from this issue.  Can you explain the fix again?  I don't see anywhere to add the redirect...