Significantly improve ease of use

[adalinesimonian]

This repository has bloated in scope and since become difficult to get up and running for a healthy number of users, that have, as a result, spent a considerable amount of time with @christiansmith and myself in hangouts trying to get them up and running, not before it started to take so long as I had to provide the users a copy of an express app I keep locally which is configured to work with Anvil Connect.

I propose we identify the exact factors that are making this repo a deployment pain and work out a plan of action. This repository was, and is, meant to be a quick-and-easy demo app that any user, anywhere, can get up and running in a flash.

[ikb42]

I concur! Trying to get this running myself, have registered a client using the CLI, and used that ID in my instance. App loads, signin button click just flashes "...was successful" as do protected and scoped buttons.
I don't get a signout button and I don't get any dialogue offering sign in.
Would love to have a working example, can I get yours @vsimonian by any chance?

[adalinesimonian]

I've been using https://www.dropbox.com/s/23bo9kj96ghsub9/anvil-connect-test.tar.gz

Open app.js and you'll see some placeholders for the issuer URL, client information, and such and so.

It uses passport-openidconnect, which is far from optimal, and doesn't provide as much details about the connection as I'd like. But it should work enough to see if Anvil Connect is working.

[ikb42]

Thanks @vsimonian that does work, I get the login / create user page and it works.

Is it worth reporting here on problems I am getting as I go along with connect-example-angularjs or should I drop this for now?

[adalinesimonian]

Your feedback on this repository is immensely helpful, though I am in no position to force you to keep trudging along with it. :) By all means, do and/or use whatever you find most practical.

[christiansmith]

I think automating setup of this AngularJS app was absolutely the wrong way to go. It was originally a local testbed for building the anvilresearch/connect-js client library, and later seemed useful as an example for how to use AngularJS with Anvil Connect.

But it defeats that purpose entirely if we automate to the point of discouraging people from looking under the hood. It's also clearly become a problem as we make changes on the auth server side and all this extraneous stuff breaks.

I take the blame for letting it get to this point. I've been working with a version prior to all these shell scripts and dockerfiles and manually configuring the client when I need changes. I just run the app locally against my development server with grunt serve.

Thinking we should just toss everything else and ship the example with a static server w/ssl support and instructions to:

• register a client with the proper configuration for this app using existing tools like nvl
• edit the files necessary to reflect the client registration
• generate a self signed cert
• start the server

There just doesn't need to be anything more sophisticated in this repo.

[henrjk]

One goal of having the build script generate the registration script was to ensure that the client is registered in the way the code is implemented. One benefit is that it makes it more explicit how this is connected.
Unless we had an automated test which verifies that setting up the example works with the latest connect code and particular for release(s), I fear that whenever somebody tries this some issue will popup.
And of course then the script could be the cause of the error also and make things even more complicated.

I was just starting to work on changing the register client script to use the new cli when I found this issue which suggests to replace the script and remove the associated Gruntfile pieces and replace them with better instructions.

A concern is that these instructions will get outdated and broken as well unless they are frequently tested. The example was broken when I first approached it also. I don't remember the details but it required debugging quite deeply and get help from the chat room on gitter. While this was educational it should not be needed to get the sample running. My initial expectation was that this would be done in a flash just as @vsimonian suggested.

One benefit of doing instructions is that they are quicker and easier to change by anyone.

When something did not work so far finding the cause often required to actually debug the code. Should there be more logging to help discover simple mismatches more easily?
Sometimes there are probably tricks of the trade such as setting certain DEBUG or NODE_DEBUG variables. Perhaps these could be collected in a troubleshooting section.
A troubleshooting section could also have a link to search for issues like this one.

[henrjk]

@ikb42 I saw the behaviour you have been seeing also (App loads, signin button click just flashes "...was successful" as do protected and scoped buttons.)

I believe what was causing this for me was that the callback was not correctly setup. What happens is that the apps web server mod-rewrites the request to index.html. After fixing the configuration issue I noticed that the user was already signed in. After signing out first the sign in page was then rendered as expected. There is also a place in app.js here which must match up.

This is all a bit off the cuff but I hope it helps in case you (or somebody) is working with this example.

Updated: minor reformatting