I have two Rails applications, let's call them A and B. A has existing user base and i want these users to be able to log in to B with the username and password managed in A.
B is altered version of Altered Beast forum and it would be nice if users of my application do not have to create another user account to use forum. My initial thought was just to swap out the User model with ActiveResource model. Forum is hosted on a different server so direct database connection to A's database is too much trouble.
My question is that is there any plugins or authentication system extensions that handle this kind of setup.
Altered Beast uses the restful_authentication plugin. Could you not just use the same plugin in application A pointed to the same database?
Edit:
Use a cooooooookies from application A.
Related
I'm about to finish building a simple subscription based support ticket Web app. I'm setting up authorization. But since this it's going to be my very own Web app that I'm going to deploy I'm wondering about this.
Do you create a separate database per account opened?
Let's say you have this support ticket Web app. You have ONE and ONLY ONE account owner. Account owner can setup agents that can respond to support tickets. Also, there are customer roles that open support tickets.
So as you can see the database will contain users, support tickets and more.
What is the best way to go?
1) Create one database for the whole application? That way every time somebody signs up, everything is added to the same database with the other tickets and users data and everything else or...
2) Everytime someone signs up, create a separate database per account subscription.
I'm thinking that maybe option number 2 would be a best choice for security and data integrity purposes. If so, how have you gone about tackling this issue?
It sounds like what you want is Multitenancy:
Multitenancy refers to a principle in software architecture where a
single instance of the software runs on a server, serving multiple
client organizations (tenants). Multitenancy is contrasted with a
multi-instance architecture where separate software instances (or
hardware systems) are set up for different client organizations. With
a multitenant architecture, a software application is designed to
virtually partition its data and configuration, and each client
organization works with a customized virtual application instance.
- Wikipedia article on Multitenancy
This article while a little dated is the general idea of how I would go about doing it. Simple Rails Multi-Tenancy. It's clean and efficient and saves you from writing code that you don't need to.
You should go for option #1. Number 2 is (almost (there are probably cases where it is good, but I can't find one at the moment)) never an option.
You are right in security purposes (well, in a sense), but it also creates a lot of other problems that you will have to think about.
Having a different database for each user means that for each request (remember, HTTP is state-less) you will have to open up a new connection to the database, do whatever needs to be done and then close the connection again, instead of using the connection pooling that is in Rails. This affects the performance a great deal.
Administration will be a hassle the more databases you have. Also, having multiple databases on a server do require more resources than just a bigger database.
You would have to circumvent the entire connection handling in Rails since there it is usually one database per application. It is easy to change the database for specific models, but it adds additional places where things can go wrong.
Rails do have good functionality for scoping and handling of separating data within the same database, just for that kind of use-case that you are mentioning.
I need to create a web app where people will sign up, call it main-app.com, when they sign up my code will generate a usersite.my-app.com, they will login and only be able to manage their mini site. My question is, is it correct to model this out by creating a table for site, a table for user, users belong to site and site has many users. Then I should create a content table that belongs to user AND site?
Is that right?
I am working on this for one of my apps at the moment using the Devise authentication plugin.
To get the central user environment, I was simply going to shard the database using Octopus, Connection_ninja. All are on Github
It's a starting point but not the full solution I'm afraid as I haven't got there myself yet. There are going to be issues to consider such as determining authorization of app specific resources based on which site the user has registered.
Alternatively, The latest edition of Ruby Weekly links to an interesting article on a Ruby implimentation of the Central Authentication Service protocol. It will be worth a read - http://blog.econify.com/2010/12/introducing-classycas.html
Hope this helps a bit...
I was wondering how other people implemented this scenario. I have an internal rails app ( inventory management, label printing, shipping,etc). I'm rewriting security on the system, cause the old way got to cumbersome to maintain ( users table, passwords, roles) - I used restful_authentication and roles. It was implemented about 3 years ago. I already implemented AuthLogic with ruby-ldap-net to authenticate users ( actually that was surprisingly easy, compared to how I struggled with other frameworks/languages before). Next step is roles. I already have groups defined in Active Directory - so I don't want to run a separate roles system in my rails app, I just want to reuse Active Directory groups - since that part of the system is already maintained for other purposes ( shared drives, backups, pc access, etc)
So I was wondering if others had experience implementing permissions/roles in a rails app based on groups in Active Directory or LDAP. Also the roles requirements are pretty complex.
Here is an example:
For instance I have users that belong to the supervisors group in AD and to inventory dept, so I was that user to be able to run "advanced" tasks in invetory - adjust qty, run reports, however other "supervisors" from other departmanets, shouldn't be able to do this, also Top Management - should be able to use those reports (regardless weather they belong to the invetory or not), but not Middle Management, unless they are in inventory group. Admins of the system (Domain Admins) should have unrestricted access to the system , except for HR & Finances part unless they are in HR ( like you don't want all system admins (except for one authorized one) to see personal info of other employees).
I looked at acl9, cancan, aegis. I was wondering if there are any advantaged/cons to using one versus the other for this particular use of system access based on AD. Suggest other systems if you had good experience.
Thank you!!!
ActiveLDAP (Documentation, Github) has some of the features you're looking for, specifically:
You can map LDAP objects (Object Class instances) to objects in a Rails application. The API doesn't mirror ActiveRecord exactly, but it's pretty easy to understand and learn.
It's obviously not possible to join, etc. across LDAP and Relational Databases, but you could write some mildly clever code to make composite data easily accessible from either the ActiveLDAP object or the ActiveRecord object.
ActiveLDAP also provides methods to write to LDAP which allows you to manage your users and roles in LDAP from rails, eliminating the requirement to manage a user table in the database, however, a user database table would likely still be necessary to store application specific data about a user.
Additionally, you could integrate AuthLogic with ActiveLDAP. Here's one attempt I found of just that: LDAP Pass-through Authentication with Authlogic and ActiveLdap
You could then use Declarative Authorization (Pundit) to handle your roles and authorization.
We have an admin application used to manage member data and it was built in 2.1, has been running for about a year. Now that all inputs and data massage is done, our client wants to start building member site, members will have access to data the administrators have been inputting.
Here's the question, should we start a new Rails app hooked to the same admin database or should we create a new Rails app in different db with master-slave settings? The good thing about creating a new Rails app is obviously taking advantage of the new version, which we like. Or ..maybe just build the member site in the same admin app?
THanks,
Why don't you want to build the member site in the same admin app? Too much legacy?
You can use the same database but the problem is you will have to enforce any conditions you have in your models directly in your database (mandatory fields, model relationship and so on).
And I can see a lot of duplication code happening between the two apps. At least for the models. Which is really wrong :(
I don't recommend making two separate applications but It is hard to answer without looking at your app and without knowing more details.
Or build a new app using a copy of the existing database?
There's no reason the two applications cannot share the same database.
However, there's probably a number of reasons why they shouldn't. But, the only way you're going to figure those out are by going through the changelog of ActiveRecord's database adaptors.
It's an application that we use internally at the office that I would like to offer as a hosted service for anyone.
How can I do that without making major code changes?
The first thing that occurs to me is to have the app select which database to connect to based on the domain.
So each instance of the app would have its own database, but all instances would share the same code.
The only changes required to the code would be the database selection.
Is this approach maintainable? I've heard wordpress.com does this and that it offers a couple of advantages. I'm mainly looking to do it this way to avoid have to scope my entire set of database queries to a certain site within the same database.
Thanks!
The simplest way to do this is to clone the application, and create another server instance to handle it. This actually the way I handle multiple wordpress blogs on my server
Pro:
This process can be streamlined into a utility script.
Can be easily maintained if symlinks are used for the common code. IE: Everything but branding and some of the things in the config directory.
Cons:
- If you're using passenger it will require an apache restart for each new instance.
- Same if you're using Apache to route subdomains on different virtual hosts to different mongrel clusters.
However the better way comes from the question: Rails - Separate Database Per Subdomain
The method in the accepted answer is much more robust. It might require more changes than you're looking for, but it has all the benefits without the drawbacks of any other methods. Each new instance requires a new entry in the master database with the table name and other instance specific information. You'll also want custom rake task to build the database for each new instance.
I would suggest switching the database connection and adding a view_path based on the domain, I have posted code in this question.
I hope this helps!
I wouldn't do this with multiple databases as you mentioned. Keeping all your schemas/migrations in sync with all the db's could become painful.
I would look into simply making it a multi-tenant app where you have some sort of "Account" model and then all your existing models are scoped to it ... in other words, if this was a blog app, your Account has_many :posts, etc.
With this approach, you can identify accounts by subdomain ... have people choose their subdomain when they create an account and go from there.
It's pretty straightforward to do. If you need add billing into the mix, you might look at the SaaS Railskit (which handles all the signup and subdomain stuff) or Chargify.
You can also identify accounts Twitter-style ... with http://myapp.com/someuser