Noobish issues

[Martijn Rammeloo]

Hi,

 

I am the developer of the 'EHAM Gate Planner', a web based tool to [Mod - Happy Thoughts]ist GND controllers at Schiphol to [Mod - Happy Thoughts]ign gates to inbound flights. Yesterday someone started 'playing' with the planner, and although this was rather harmless, it would be really annoying if it happened during a busy event. Therefore, I am exploring options to put the web page behind a p[Mod - Happy Thoughts]word, and the VATSIM SSO seems like a promising solution.

 

However... after uploading the files and filling in the info in the config file, I receive the following errors:

 

Warning: openssl_sign(): supplied key param cannot be coerced into a private key in /home/rammeloo/domains/rammeloo.com/public_html/ehamgateplanner/OAuth.php on line 511

 

Warning: openssl_free_key() expects parameter 1 to be resource, boolean given in /home/rammeloo/domains/rammeloo.com/public_html/ehamgateplanner/OAuth.php on line 514

An error occurred

 

Error code: 6

 

Error message: Couldn't resolve host 'api'

 

 

The info I entered in the config file:

$sso['base'] = 'http://sso.hardern.net/server/';

$sso['key'] = 'SSO_DEMO';

$sso['secret'] = 'js8Sm7nit-2a_~k_~My6_~';

$sso['return'] = $http.$_SERVER['SERVER_NAME'].$_SERVER['PHP_SELF'].'?return';

$sso['method'] = 'RSA';

$sso['cert'] = <<

-----BEGIN RSA PRIVATE KEY-----

MIIE...

...RMR

-----END RSA PRIVATE KEY-----

EOD;

 

I did not change any other file. Any idea what I did wrong?

 

KInd regards,

 

Martijn

[Jamie Fox 811029]

Is likely that this error is due to there being a problem with the private key.

 

Please double check that the private key in your config file matches exactly the one given for SSO_DEMO in the Demo Credentials thread. It's 15 lines of base64-encoded text, starting with MIIE and ending with QRMR.

[Martijn Rammeloo]

Jamie,

 

Thanks! The problem was something else however... My webhost experienced 'issues' this afternoon. As a result, notepad++ couldn't upload the edited config.php file, but I didn't notice that.

 

This step works perfectly now!

 

I will probably have some more questions at a later moment

 

Kind regards,

 

Martijn

[Martijn Rammeloo]

Follow-up questions...

 

- At a certain point in the example index.php file, it shows: "NOTE: In a live environment, save these details and then redirect the user". Therefore, I [Mod - Happy Thoughts]ume this index page is the 'gatekeeper' for the 'real' page (i.e. 'frontpage.php'). However, how do I make sure that a user cannot go directly to frontpage.php, by-p[Mod - Happy Thoughts]ing the login in the process? I guess there must be some check at the beginning of frontpage.php, but I cannot find a reference in the docomeentation.

 

- Is a specific redirection technique required for the authentication to keep functioning?

 

Kind regards,

 

Martijn

[Jamie Fox 811029]

This is really the boundary where SSO stops and your own code begins - what you want to do next will depend entirely on what you want to do with the data.

 

At line 46 on index.php, the user has successfully authenticated with SSO and you now have their data, including their CID, name, etc., in the $user object. The demo system, being only a demo system, just prints this out to show you that it worked, but does nothing else. Typically you might want to store the CID in a session variable, to remember the authentication for the session, and save some of the user data in a database so that you have persistent access to the data - you probably want to save at least the member's full name. Then just make sure you update this data each time they log in via SSO, in case it has changed.

 

When the user is returned to index.php from the VATSIM SSO site, they come some data (a token) in the $_GET query string variables. The $SSO->checkLogin call on line 43 is contacting the SSO server directly (from your web server) and checking that the token provided by the user matches the one that SSO just recorded, thus proving that your user is the same one that just authenticated at SSO. If the token doesn't match there will be an error.

 

The demo index.php is set up so that they are redirected from here, and back to the same page. So if a user loads index.php with no query string, they will just get redirected to SSO to log in. When it's loaded for the second time (i.e. user having been returned from SSO) this is detected via the presence of extra $_GET query string data - that data would have to be correct in order to authenticate.

[Martijn Rammeloo]

OK, thanks, time for some experiments!

 

Martijn

[Martijn Rammeloo]

@Jamie, everything is working , on the live server. Once again, thanks for your help!

 

Martijn