"Unexpected error" after login

[rwillmer]

I've got this partially working for me, but it's falling over at the final stage of the login process.

I have a login button on the meteor site.

When I press it, the popup comes up with the CAS login at the CAS server.

When I login, the CAS server logs confirm that the login was successful.

But then the meteor popup changes to a URL similar to "http://localhost:3000/_cas/Y6syhx3saqcoAsxp5?ticket=ST-1393497698-X0NiTItRHfay9XepSAwqhS1U0hL8E5qU" and the popup text says only "Unexpected error".

The meteor server shows this:

W20140227-10:41:38.463(0)? (STDERR) 
W20140227-10:41:38.464(0)? (STDERR) events.js:72
W20140227-10:41:38.464(0)? (STDERR)         throw er; // Unhandled 'error' event
W20140227-10:41:38.465(0)? (STDERR)               ^
W20140227-10:41:38.465(0)? (STDERR) Error: getaddrinfo ENOTFOUND
W20140227-10:41:38.465(0)? (STDERR)     at errnoException (dns.js:37:11)
W20140227-10:41:38.473(0)? (STDERR)     at Object.onanswer [as oncomplete] (dns.js:124:16)
=> Exited with code: 8

Any ideas about what the problem is, or how I can debug it?

[atoy40]

Hello,

are you sure to have a correct value for cas.baseUrl ? because it is used to validate the ticket, and in your case, it seems to get an error to resolve the server name.

Anthony.

[rwillmer]

Hi Anthony

Thanks for replying! This is my settings.json

{
  "cas": {
    "baseUrl": "https://127.0.0.1:8080/cas/",
    "autoClose": true
  },
  "public": {
    "cas": {
        "loginUrl": "https://127.0.0.1:8080/cas/login",
        "serviceParam": "service",
        "popupWidth": 810,
        "popupHeight": 610
    }
  }
}

What should cas.baseUrl be? on the CAS server? or the meteor server that's trying to use it for authentication?

localhost resolves OK to 127.0.0.1 on the box; and I've even changed the settings to use localhost, so I don't see where DNS resolution comes into it any more

Any pointers welcome!

[atoy40]

You have the exact same trace when using ip address ?
Your baseurl looks good.
May be a side effect of having cas server on localhost ? (never tried this)

Can you try to add a console.log call into cas_server.js ? for example, start at line 20, to check if the handler is called for "/_cas/" URLs ? then try to move down the console.log() to find where the exception start.
The strange think is you very "poor" stacktrace.

Anthony.

[rwillmer]

Thanks, I'll try that. It might be a few weeks before I comment back, I'm about to go offline for a couple of weeks, and may not get Internet access again while I'm away.

[bjconlan]

I encountered the same issue (using a self signed certificate on localhost).

I've setup my environment for development/integration testing (as per https://wiki.jasig.org/display/CASUM/Best+Practice+-+Setting+Up+CAS+Locally+using+the+Maven+WAR+Overlay+Method) and discovered/resolved 2 issues that might need addressing/documentation (none of which mind you are in this wonderful meteor plugin (thank you atoy40) but in the dependencies/node configuration):

The first issue I found was that the CAS node module doesn't extract the 'hostname' correctly which leads the validation function's https request using a 'host' (hostname:port) as well as a port.

I fixed this by simply reassigning the hostname as the host before the validation function is called (but this is hacky and should really be fixed in the cas dep...)

cas.hostname = url.parse(base_url).hostname; @ line 67 of cas_server.

This will then lead to the nodejs https client failure due to having a self signed certificate outputing something like: Error: DEPTH_ZERO_SELF_SIGNED_CERT.

To fix this I added process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0'; into my applications bootstrap.js (where my meteor settings are configured).

[atoy40]

Thank you @bjconlan !
i'll add a note in the README for the self-signed certificate issue.
For the cas bug, i think i will add this part in the meteor extension directly, it's a very small piece of code to validate a CASv1 ticket ... so i'll fix it :)

Anthony.

[konsumate]

@atoy40 I stumbled upon this one today, the mentioned fix above never made it into the code, right?