trouble diagnosing persona issues

[pmuellr]

I'm running a server, but not able to get the persona login to work. I can't get anything other than failure while logging in.

I've used persona on other sites, so I know my "basic" persona skillz are ok - none-the-less, this is most probably an error on my part. Or is some configuration required which isn't I didn't notice in the docs?

Anyhoo, before I dive in, I'll just note that there aren't really any good diagnostics for this particular failure. Here are the symptoms:

• a red list item at the top of the browser page which says Error on /persona_login: FAIL in red
• Chrome DevTools shows a POST to https:///persona_login which is getting a 401 (Unauthorized). The form data posted is the persona assertion (long), the response pay load is FAIL.
• the server prints the following:

[ 'isAuthenticated? owner=',
  '',
  'req.session.email=',
  undefined,
  false ]

[WardCunningham]

I haven't seen this error so we are in new territory, at least for me.

The red list item is the crude way the client software reports unexpected server errors. This is consistent with the unexpected 401 from the server.

There has been some debug output left in the server. That must be the json you are seeing from it. I'm guessing that crucial information (owner, email) was somehow blocked before this message. I'm heading for a plane or I'd hop into an editor and find where this gets printed. @paul90 is pretty familiar with this code so I mention him here hoping he will make a suggestion.

[pmuellr]

I think what's happening is that

• I'm running this on a cloud, which runs it on some wacky internal port, exposing to the world through DNS mapping as a port 80 server
• the persona audience is being set to essentially localhost:wacky port, which is the failing in verification

I tried fooling the code into thinking url is "", so that it would use the host header from the request, but ... defeated at every turn. There doesn't seem to be a way to set it to "", if the port isn't 80, or something. I'm not sure that's the safest thing to do anyway.

I think the "fix" for me is to pass the valid URL.in the configuration.

But I think it would be useful to dump the persona request (don't need the assertion, but audience would be nice) along with the persona response, upon failure.

[WardCunningham]

The "fix" sounds like a good next step. Let us know how it works. Keep notes on what you have to do so we can accumulate How-Tos for various services.

[paul90]

The url parameter needs to be set to the address that is exposed to the outside world - which means that any default the server constructs will be wrong.

Might be worth looking at wiki-openshift-quickstart for an example of a OpenShift solution, using the platform's environment variables to construct a configuration file.

An issue is that if the server is accessible by both http and https, persona will only work with one of them - as the url parameter is hard-wired.

With the server running in the cloud, it the server will not be able to set the correct values itself as it will only see the internal address/port - and not the external exposure.

Note: if the wiki is accessible via both http and https, only one route will currently be able to used to login - whichever is hard-wired into the url parameter.

[pmuellr]

Right. For clouds that give you both an http:// and https:// routing, for the same app, you can only pick one to use that persona will work with.

Which is a little unfortunate, but it's also a bit weird that clouds expose both, and don't always give you an option to route one to the other (eg, expose both http: and https:, but forward all http: traffic to the https: side).

One way that we could support both, would be to swizzle the protocol in the passed-in url config from ... hmmm ... the referer header? blech. Would likely work.

Or making use of X-forwarded-for, or something.

Probably not worth the effort, as the calculation of the url gets more complicated.

Some write-up on this, in the readme? might be appropriate.

[paul90]

I'm wondering - one possibility would be to re-try the other protocol,
for the audience, if the first call to the verifier fails.

Though using X-forwarded-proto to guide whether to use http or https
might be a better solution.

Patrick Mueller mailto:notifications@github.com
29 October 2013 18:42

Right. For clouds that give you both an http:// and https:// routing,
for the same app, you can only pick one to use that persona will work
with.

Which is a little unfortunate, but it's also a bit weird that clouds
expose both, and don't always give you an option to route one to the
other (eg, expose both http: and https:, but forward all http: traffic
to the https: side).

One way that we could support both, would be to swizzle the protocol
in the passed-in url config from ... hmmm ... the referer header?
blech. Would likely work.

Or making use of X-forwarded-for, or something.

Probably not worth the effort, as the calculation of the url gets more
complicated.

Some write-up on this, in the readme? might be appropriate.

—
Reply to this email directly or view it on GitHub
https://github.com/WardCunningham/wiki/issues/36#issuecomment-27331147.

Patrick Mueller mailto:notifications@github.com
29 October 2013 15:14

I'm running a server, but not able to get the persona login to work. I
can't get anything other than failure while logging in.

I've used persona on other sites, so I know my "basic" persona skillz
are ok - none-the-less, this is most probably an error on my part. Or
is some configuration required which isn't I didn't notice in the docs?

Anyhoo, before I dive in, I'll just note that there aren't really any
good diagnostics for this particular failure. Here are the symptoms:

a red list item at the top of the browser page which says |Error
on /persona_login: FAIL| in red

Chrome DevTools shows a POST to https:///persona_login which is
getting a 401 (Unauthorized). The form data posted is the persona
assertion (long), the response pay load is |FAIL|.

the server prints the following:

|[ 'isAuthenticated? owner=',
'',
'req.session.email=',
undefined,
false ]
|

—
Reply to this email directly or view it on GitHub
https://github.com/WardCunningham/wiki/issues/36.

[hallahan]

I have gotten Persona working with wiki running port 3000 and NGINX reverse proxying via 80. The trick is that you MUST STATE BOTH 1) the port and 2) the intended URL in your startup params:

./index.js -p 3000 -u http://wiki.theoutpost.io

Missing either of those params makes login fail.

[hallahan]

Hmm, I think I tricked it into working, but it is not working any more. I have reverted to only logging in when going in on port 3000. With that in mind, I need to start the server as follows:

./index.js -p 3000 -u http://wiki.theoutpost.io:3000

And only log in via port 3000

[almereyda]

I have two wiki farms running.

---

First one is started as an upstart service

description "sfw farm"
author      "kvz + almereyda"

# used to be: start on startup
# until we found some mounts weren't ready yet while booting:
start on runlevel [235]
stop on runlevel [016]

# Automatically Respawn:
respawn
respawn limit 99 5

export HOME="/root"
NOW=$(date +"%Y-%m-%d")

script
  source ~/.nvm/nvm.sh
  nvm use 0.10
  mkfifo /var/www/wikifarm/logs/fifo
  ( logger -t wikifarm </var/www/wikifarm/logs/fifo & )
  exec >/var/www/wikifarm/logs/fifo
  rm /var/www/wikifarm/logs/fifo
  exec wiki --config /var/www/wikifarm/wikifarm.json 2>> /var/www/wikifarm/logs/wikifarm.$NOW.log
end script

The wikifarm.json as follows

{
    "host": "127.0.0.1",
    "data": "/var/www/wikifarm/data/",
    "farm": true
}

My public wikifarm at `.wiki.allmende.io uses the following nginx config

server {
    listen 80;
    server_name .wiki.allmende.io;

    access_log  /var/www/wikifarm/wiki.allmende.io.access.log;
    error_log  /var/www/wikifarm/wiki.allmende.io.error.log;

client_body_in_file_only clean;
client_body_buffer_size 32K;

client_max_body_size 10M;

sendfile on;
send_timeout 300;


    location / {

        proxy_pass http://127.0.0.1:3000;
        proxy_redirect off;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $remote_addr;

    client_max_body_size       10M;
    client_body_buffer_size    32k;
    client_body_in_file_only clean;

    proxy_connect_timeout 300;
    proxy_send_timeout 300;
    proxy_read_timeout 300;

    proxy_buffer_size 4k;
    proxy_buffers 4 32k;
    proxy_busy_buffers_size 64k;
    proxy_temp_file_write_size 64k;


    }

}

I believe it makes sense to rely on the npm wiki metapackage instead of running wiki-node-server alone. Persona works just fine there. Try it out by creating a new wiki and claiming it.

---

Persona does not work for TLS + HTTP basic auth secured wikis, as the callback cannot pass the authentication. But local wikis, DNSed in my private router, or just by /etc/hosts, also successfully return the callback.

I will update this thread with the respective systemd, farm and nginx config.

[hallahan]

I think I figured out what's going on here. It's not the reverse proxy. I'm using pm2 (similar to upstart) to keep the process alive, but the command line arguments are not passing through.

Everything works fine when I manually go in the command line and start it as such:

./index.js -p 3000 -u http://wiki.theoutpost.io

Then, I can use persona just fine through NGINX.

So, I need to figure out how to start the wiki using a "config file" rather than command line args. Are there any instructions on how to do this? Do I make some sort of config.js file and put it somewhere?

[WardCunningham]

Server options are described in the ReadMe.
https://github.com/fedwiki/wiki-node/blob/master/ReadMe.md#server-options

A config file might look like this:

{
    "farm": true,
    "data": "/Users/ward/Smallest-Federated-Wiki/data/farm"
}

[hallahan]

Cool. I figured out that if I have a config file for pm2, I can do pm2 start config_file.js. Then I make my config file have this:

{
  "apps" : [{
    "name"        : "wiki",
    "script"      : "/usr/lib/node_modules/wiki/index.js",
    "args"        : ["-p", "3000", "-u", "http://wiki.theoutpost.io"],
  }]
}

Doing this resolves my issue.

Now my question is: How do I get in neighborhoods so my wiki can be discovered by your wikis? Sorry, I've been out of the loop for a while...

PS: The wiki config file route still requires a parameter of --config to point to the config file. So, that option doesn't actually solve it...

[WardCunningham]

You can put the config file in the root or current working directory. Then you need not specify --config.

I have two sites for you listed in sites.fed.wiki.org.

Well documented SEO techniques work too.

[paul90]

With pm2 you need to pass the parameters to your application slightly differently, the following example is from the PM2 advanced readme:

$ pm2 start app.js -- -a 23  # Pass arguments '-a 23' argument to app.js script

Any parameters after the -- will be passed to the application.

[almereyda]

@paul90 is right here, because it also allows you to pass custom parameters to pm2 and your application like

$ pm2 start app.js --name "My Wikifarm" -- --config wikifarm.json

A while ago another process manager for Node appeared on the scene, which seems pretty interesting to discover https://github.com/tableflip/boss