When a new user arrives at the Web AppBuilder (Developers Edition), they are prompted for the full URL of their portal or ArcGIS Online for Organizations subscription. This is practical for users running the application locally, but if we’re standing this up in a shared (or potentially public) deployment, we need to be able to lock this down to our organization’s subscription, and not allow users to specify a different URL. Is there a way to control this?
The Web AppBuilder Developer version is not meant to be an application that is shared amongst your users. You develop your app then you download your app and then deploy to a web server to be shared for your users.
Robert, thanks for your response. I've been looking for a way to pass apps to another Web AppBuilder. For example if I make an app with my Web AppBuilder and deploy it, but then find that some changes need to be made, is there a way to take that app and give it to someone else to make the changes with their own Web AppBuilder? It seems like I should be able to copy the the application into the server\apps folder but my guess is there is more to it then that.
Sure there is. In Web AppBuilder there is an import button on the main screen this allows you to import a configured app from AGOL. In Web App Builder Developer edition 1.1 released today there is also the option to import from local computer.
I agree with Robert that Web AppBuilder is not meant to be shared like that. However one possible scenario could be this.
just to throw this out there, I was able to copy the entire WAB folder to a new machine, register it under the same app inAGOL and Fire it up on the second machine. It could see what I developed on the other machine...but local on the second machine. granted, keeping these in sync could become an issue right away, but it is possible to share that way. Most likely refreshing the entire web-app folder once in a while might work. It was just me playing, not sharing with someone else, so not testing in the real world.
We (David and I) successfully followed the instructions for running the WAB as a windows service, and multiple users can connect using either Esri or enterprise credentials (via SAML) and confgure applications, however two main concerns arose in our testing:
And although we had some success using IISNode and the IIS7 URLRewrite module to try and route traffic from port 80 to node.js in a controlled manner (without routing 100% of traffic there), there were too many calls to the node.js root (rather than a predictable, filterable path) to make this a practical reality similar to a tomcat webapp. Discussions with Esri's developers and support techs haven't gotten very far, if anyone else out there is trying to work through some of these details, we'd appreciate the discussion. Thanks!
I believe that you are attempting to use Web AppBuilder in an unintended manner. My understanding of the Web AppBuilder design is that a developer or configurator will use Web AppBuilder to built a stemapp site and then that stem app is deployed for use to your intended audience. I don't believe that trough all my talks with the dev team that your workflow was ever intended to be supported.
Thanks, Robert, it sounds like our experience in discussing this pattern with Esri developers has been consistent with yours - that it wasn't anticipated or intended. Nevertheless, we have been hearing this functionality repeatedly and insistently requested by our customers - they want a Web AppBuilder experience similar to the ArcGIS Online version where they have the freedom not just to tweak a few widget settings on a preconfigured app, but to choose from an expanded list of widgets (and themes) in a fully online interface. And despite the fact that Esri seems to have not anticipated this scenario, the developer edition of Web AppBuilder functions surprisingly well in this shared environment, with only the few small aforementioned issues. We can and will submit this as an enhancement request on ideas.arcgis.com, but wondered whether the developer community was hearing similar requests and had already managed to hack together a solution. As always, very much appreciate your insight!