Single sign between Vbulletin and rails applications

Question

We have many users on the VBulletin forum. Now I want to write some more applications on rails for the same user base. So far, VBulletin takes care of all authentication and session management. What is the best way to provide SSO for my users, both onVBulletin and the rails apps I write

---

I am working on a single sign-on process using v Bulletin and a custom application. I can log in to Vb using cookies. I can access everyone. but when access is sent "Private Message". He says

"You have disabled private messages. You cannot send private messages until you enable them by editing your settings."

are there any permissions in the "datasource" table? ..

Thanks master

Answer 1

Ideally, your two sites are subdomains of a common domain (for example, forum.example.com and rails.example.com ) or share the same domain ( www.example.com .) One of the sites will be the primary authenticator and set a cookie ( for .example.com in the case of a common parent domain [pay attention to . before example.com ] or www.example.com in the case of a common domain so that both applications can access it), where the cookie contains:

• user ID
• a salt (random value calculated during login) and
• a SHA-2 signature , calculated by the triplet ( user ID + salt + a shared secret key ), where the shared secret key is the secret string known by both sites.

Each site will be able to extract the user ID and salt from the cookie, and then use the shared secret key (known only by two applications) to calculate the SHA-2 signature , which should correspond to the stored SHA-2 signature in the cookie.

If the SHA-2 signatures match, you can assume that the user is authenticated, otherwise force the user to log in again.

The cookie must be destroyed upon logout.

Small print

To protect against session hijacking, all requests made on two sites should be encrypted via SSL (use https.) If this is not possible, a hash based on the client’s IP address and browser type and version (User agent) is likely should be calculated at login time and also stored in a cookie. It must be re-checked on the client IP and user agent before serving each request. A hash approach is security through obscurity and can be tricked; in addition, a user accessing via the Internet from a proxy pool or using TOR can be called by your system every time a different proxy server or node output (with a different IP address) sends a request.