Open rwillmer opened 10 years ago
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.
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!
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.
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.
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).
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.
@atoy40 I stumbled upon this one today, the mentioned fix above never made it into the code, right?
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:
Any ideas about what the problem is, or how I can debug it?