News and Announcements

  • entries
    500
  • comments
    13,822
  • views
    4,815,995

Contributors to this blog

IP.Board 3.4 Dev Update: IPS Connect

Entry posted

30,300 views

The IPS Community Suite provides a fantastic community solution for all kinds of websites.
For many of our customers, the community is just one component of their site. Many of these customers utilise single sign-on systems for integrating the community with the other areas.

At IPS, we get requests for this on a regular basis, and over the years, I've worked on many of these solutions as part of my day-to-day workload.
Companies like Evernote and Roxio have created a single sign-on solution with the IPS Community Suite and their existing user databases.
Other companies which manage large numbers of communities like the NFL and the NHL have created a single sign-on solution allowing all their communities to share the same user database.

Creating these systems can be quite arduous though. Every setup has different ways of handling data and systems must be created bespoke to each situation.

6 years ago, we had an idea to simplify this. What if we could create a solution that would allow a network of web applications to share user information? We created a solution and called it IP.Converge.

Over these 6 years though, the internet has changed. IP.Converge was designed to be a "master" in a network of "Converge compatible" applications. This approach had two main shortcomings: firstly, it is often the case that our software needs to be the "slave" in a single sign-on network, secondly, the approach was too general which made both facilitating full single sign-on (where users are automatically logged into all applications after logging into one) was difficult, and making non-IPS software compatible with Converge was extremely difficult.



Fortunately, we think we've come up with a better solution. As of IP.Board 3.4, we are completely removing support for IP.Converge, and have developed a new system, which we're calling IPS Connect.


IPS Connect has no central application. In an IPS Connect network, one of the applications will serve as the master, and there will be any number of slaves working off it.
When writing IPS Connect, we had three main objectives: [*]Single Sign-On must be completely automatic and effortless. After logging into any application in the network, the user should be automatically logged into all others. And similarly, after logging out, the same. [*]The process should be completely transparent to the user. The user should be able to register an account, or update account information on any application in the network, and these changes should be pushed transparently to the other applications. [*]It should be easy for developers to make their web applications compatible with IPS Connect - and they should be able to make their web applications serve as either the master or the slave. So what does this mean? As of IP.Board 3.4, it will be easy, and completely seamless to create a single sign-on network between 2 or more IP.Boards, and 3rd party developers will also be able to write support for any other web application to join in in the network. How does it work? For the simplicity of this example, let's say you're networking 2 IP.Board installations. The "master" installation has a secret key which will be given the "slave" installation. When a user visits the "slave" installation, IP.Board will check if they are logged into the "master" installation - if they are it will log them in automatically, creating the account if necessary. If they're not logged in, but then choose to log in on the "slave" installation - they will automatically be logged into the "master" installation. This happens transparently, without the user leaving the "slave" installation. When a user registers or updates their account, the "master" application will be pinged and updated. Again, this happens transparently. How simple is it to write support for my custom web application? Really simple! If you want your application to be the "master", all you need to do is create a single php file which "slave" applications will send requests to. This needs to do things like facilitate log ins, account registrations, etc. If you want your application to be the "slave", you simply ping that file on the "master" application when stuff happens. We've created 2 completely functional example websites which demonstrate exactly how to do this, which will be available to download when 3.4 is released.
































49 Comments



Posted

I didn't quite fully understand the concept, but seems to be a good approach! Is it going to open doors for direct integration of 3rd party applications like WordPress?

  • Loading...

Share this comment


Link to comment

Posted

Finally! Thanks!

ZackL likes this
  • Loading...

Share this comment


Link to comment

Posted

This looks excellent! I'm working on a custom site that I want to integrate with one of my IP.Board communities, and it sounds like IPS Connect will make it much easier to do this than poring over the IP.Converge documentation. I look forward to snooping through the two example sites to see how it works. :)

I have a couple of questions: [*]Does IPS Connect require all "connected" applications to reside on the same domain, or can it handle cross-domain SSO as well? [*]Does the mentioned "updating of account information" on any site in the network apply only to the username, password, and email address, or can IPS Connect handle all kinds of account data like avatars/photos, profile fields, "about me" text, etc.?
Cross-domain SSO and a straightforward API for sharing account data will make IPS Connect a true ace in the hole.




  • Loading...

Share this comment


Link to comment

Posted

Here's the one big question I have. Using two IPB's as an example, if you ban or ModQ a member on one, will it affect the other or is that still a limitation as was with IP.Converge?

Sokii, AlexJ, mrcikeprcike and 5 others like this
  • Loading...

Share this comment


Link to comment

Posted

Would it be possible to migrate from IP.Converge and use your default SSO in 3.4?

Also what would happen if you delete one user from master forum? Would it be deleted from all slaves as well?

  • Loading...

Share this comment


Link to comment

Posted

Oooh nice. I have a question...can the master be changed?

mrcikeprcike and AlexJ like this
  • Loading...

Share this comment


Link to comment

Posted

NICE AT LAST

  • Loading...

Share this comment


Link to comment

Posted

[quote name='Srinath' timestamp='1344514807']
I didn't quite fully understand the concept, but seems to be a good approach! Is it going to open doors for direct integration of 3rd party applications like WordPress?


Yes - if someone wanted to write IPS Connect support for Wordpress, or any other 3rd party application, it would be relatively simple to do.


[quote name='Feld0' timestamp='1344517725']
This looks excellent! I'm working on a custom site that I want to integrate with one of my IP.Board communities, and it sounds like IPS Connect will make it much easier to do this than poring over the IP.Converge documentation. I look forward to snooping through the two example sites to see how it works. :smile:

I have a couple of questions: [*]Does IPS Connect require all "connected" applications to reside on the same domain, or can it handle cross-domain SSO as well? [*]Does the mentioned "updating of account information" on any site in the network apply only to the username, password, and email address, or can IPS Connect handle all kinds of account data like avatars/photos, profile fields, "about me" text, etc.?
Cross-domain SSO and a straightforward API for sharing account data will make IPS Connect a true ace in the hole.


In order for SSO to work, applications must be on the same domain (there are a few ways around this which we might look into in a future release, but I'm not particularly keen on any solution I've seen - essentially it's a limitation of how cookies work).
However, if applications are on different domains, you can still log in with the same details, you just won't be logged in automatically.

Currently we only do account information (username, email, password) - we'll almost certainly add support for additional stuff down the line, but out of the door, we wanted it to be really easy for developers to write support for other apps, and this adds complexity.



[quote name='Wolfie' timestamp='1344518803']
Here's the one big question I have. Using two IPB's as an example, if you ban or ModQ a member on one, will it affect the other or is that still a limitation as was with IP.Converge?


It will not affect the other - just like with the pictures and stuff mentioned above, we'll almost certainly add stuff like this down the line, but we wanted it to be really simple to work with to start.


[quote name='AlexJ' timestamp='1344520235']
Would it be possible to migrate from IP.Converge and use your default SSO in 3.4?

Also what would happen if you delete one user from master forum? Would it be deleted from all slaves as well?



IP.Converge maintains local databases everywhere, so you just turn off Converge, no need to migrate anything.

If you delete a user from the master, it depends if the slave has a fallback mechanism in place (the IPS Community Suite allows you to turn fallback mode on or off) - if it's turned on, nothing will change on the slaves, if it's turned off, they won't be able to log into the slaves.


[quote name='Lucy Heartfilia' timestamp='1344520293']
Oooh nice. I have a question...can the master be changed?



Yes.




Srinath, AlexJ, Feld0 and 1 other like this
  • Loading...

Share this comment


Link to comment

Posted

With five sites, you've just made me very happy indeed... well done guys...

  • Loading...

Share this comment


Link to comment

Posted

WOOHOO! This is the news I've been waiting for!

  • Loading...

Share this comment


Link to comment

Posted

Will allow us to make login methods without requiring to distribute a hook for displaying the image login image or button?

  • Loading...

Share this comment


Link to comment

Posted

Liking this :)

  • Loading...

Share this comment


Link to comment

Posted



Awesome! This is going to not only increase Marketplace apps, but also improve IPS revenue! :)

Yes - if someone wanted to write IPS Connect support for Wordpress, or any other 3rd party application, it would be relatively simple to do.

  • Loading...

Share this comment


Link to comment

Posted

I CAN'T WAIT. I've used IP.Converge for years and it always had so many problems and support was minimal until the last year or so when it completely died off so I'm really glad this is here to replace it. It seems much more efficient and easier to use.

Most importantly, it's seamless for the users on the website. Great job, IPS! Can't wait for this to be released.

  • Loading...

Share this comment


Link to comment

Posted

Revolution.

  • Loading...

Share this comment


Link to comment

Posted

Revolution x 2 = When "IPS Connect can handle all kinds of account data like avatars/photos, profile fields, "about me" text, etc"...etc etc etc!!!!.

To come out of the dark shadows and make a comment on the board, YOU KNOW I'M FEELIN THE LOVE ON THIS MOVE BY IPS!!! Looking forward to it being implemented in 3.4 and EXPANDED as said above. Niceness.

CallieJo likes this
  • Loading...

Share this comment


Link to comment

Posted

Great news!

I'd love to see the day when the profiles are condensed to one master. If you have 2 or more connections, they all link to one profile located on the master. Although, I can see the issue of users' content being a task to conquer with this unless links were provided to different connected content instead of content lists from current connection.

  • Loading...

Share this comment


Link to comment

Posted

Still with the requirement for it to be a PHP script though. Many applications within my network are not PHP, but are actually mostly ASP.NET - certainly at least the ones I'd rather designate as a master are. The connector script should really be language agnostic - if it can talk "IPS Connect" it should be able to be pointed at and used.

  • Loading...

Share this comment


Link to comment

Posted

Drupal+ip= love

  • Loading...

Share this comment


Link to comment

Posted

So this is no Facebook Connect-like addition?

  • Loading...

Share this comment


Link to comment

Posted

[quote name='Kyanar' timestamp='1344558818']
Still with the requirement for it to be a PHP script though. Many applications within my network are not PHP, but are actually mostly ASP.NET - certainly at least the ones I'd rather designate as a master are. The connector script should really be language agnostic - if it can talk "IPS Connect" it should be able to be pointed at and used.


It is language agnostic.

Everything is done over HTTP using JSON as the format for returning data.
Slave applications simply make HTTP requests to the ipsconnect.php file.
For master applications, the file must be called "ipsconnect.php", but you can easily configure the server to run .php files in certain directories as something else - and you just need to return the appropriate JSON.

  • Loading...

Share this comment


Link to comment

Posted

So what happens if the central database goes down?

  • Loading...

Share this comment


Link to comment

Posted

@Mark,

Is this just a framewaork or comeup with built-in options....?

  • Loading...

Share this comment


Link to comment

Posted

Can IPS Connect handle SSO between subdomains of the same domain with automatic login?

What about Facebook Connect... it will work ok with IPS Connect?

Thanks.

  • Loading...

Share this comment


Link to comment

Posted

[quote name='K4RL' timestamp='1344591951']
So what happens if the central database goes down?


If fallback mode is enabled, and they've logged into that slave before, login will work, but automatic login won't.
If fallback mode is not enabled, logins will fail.

[quote name='Srinath' timestamp='1344601100']
@Mark,

Is this just a framewaork or comeup with built-in options....?


Both. It's a framework, which the IPS Community Suite supports (so you can use it out of the box to link together two communities).

[quote name='Guaraná-BR' timestamp='1344606506']
Can IPS Connect handle SSO between subdomains of the same domain with automatic login?

What about Facebook Connect... it will work ok with IPS Connect?

Thanks.


Yes, subdomains are fine.

If Facebook Connect is used, IPS Connect won't interfere with it.

sijad and Srinath like this
  • Loading...

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now