After searching a lot I wasn't able to find a decent recent guide on how to create a admin backend on a subdomain on a RoR project - ideally allowing me also to split app\frontend and app\backend into different folders without requiring to duplicate all controllers, views, ...
I want to separate all backend related from the front end and work on the backend from a subdomain as this gives me some extra security on the server side.
Please Notice: I do want to use atctive admin and other related gems for that.
This page
http://guides.rubyonrails.org/routing.html
which is the standard documentation for rails routing, shows you how to put your admin section in a namespace accessed via a subdomain, which i think is exactly what you want to do. See Section 3.9: "Request-based constraints".
I found this by googling for "rails routes", going to the top result, and then doing a ctrl&f for "subdomain". This is the strategy i would recommend for most api questions.
Related
I've posted this on Laravel.io too, but no answer yet: http://laravel.io/forum/01-17-2016-setup-different-frontend-backend-application-endpoints
I've been struggling figuring this out but no luck yet - couldn't find an answer anywhere.
I have a regular public-facing website for which I need an admin interface. Assuming the website is at example.com, I want the admin interface to be accessible from example.com:3000.
I've tried domain routing, it doesn't seem to be working. The idea is to share all the business logic, but isolate assets and routes - for instance, accessing "/" would produce different results on the frontend (showing the homepage) and on the backend (showing a dashboard). I also need different middleware authentication, but I have a hunch that's going to be easy once I figure out how to set this up.
If it's easy to add different sessions, that would also be cool, but I can live without it.
This has been answered on laracasts: https://laracasts.com/discuss/channels/laravel/setup-different-frontend-backend-endpoints-in-laravel-51 , I'll quote from the answer here:
You can pull it off by editing the app/Providers/RouteServiceProvider
and loading in a specific routes file based on the "context" of the
application.
You could create two routes files /app/Http/Routes/frontend.php and
/app/Http/Routes/backend.php. You'll do some sort of logic in the
RouteServiceProvider to determine what route file to load in.
I'm learning Rails 4 and I'm looking to build in some basic admin functionality such as creating and viewing users. I can think of a few ways to do it manually, (such as creating a new controller or adding filters) but I'm pretty sure there's a "Rails Way" to do this easily. I've been digging through the docs and I see references to "built in authentication" that support my hunch, but I can't find the actual documentation.
For example, in CakePHP you can just prefix actions with admin_ and /admin/controller/action will work automatically. Is there a similar convention for Rails? If so, where can I find it?
Update:
As I continue to research this, I start to get the impression that admin authorization in Rails is commonly not handled by the Rails core, but rather in a gem like cancan. Perhaps this is why I was striking out by searching the Rails docs.
Update2:
This question wasn't intended to be a round-up of authorization gems, but since it appears gems are the typical way to handle even basic admin authorization, I'd like to find the simplest, most basic (and hopefully universal) option. A couple options have been proposed below which come bundled with default dashboard views and elaborate configurations. I don't need all that. Just a simple, reliable strategy for dividing users into admins and non-admins with different scopes of allowed actions.
Check out the awesome rails_admin gem. It automatically generates just about everything you could need. Very handy and awesome project. https://github.com/sferik/rails_admin
Authentication is handled via the devise gem and authorization via cancan.
It's no replacement for custom admin functionality if you have very specific requirements, but it's great for general admin tasks you described.
I've been following this tutorial on creating a backend administration section for a rails 3 app.
I like the way it works, but the developer is required to manually generate namespaced controllers and models for each resource they want to administer in the backend.
RailsAdmin, in contrast, does not require you to do this, instead it detects which models you have in your app, and sets up admin sections for each one, without you having to generate any extra code.
Are there any resources out there, where I can learn to make my admin section work a little bit more like RailsAdmin? (I tried reading the RailsAdmin codebase but I get lost as there's quite a lot going on).
Ideally, I'd like my admin section to detect my application's models, and magically create admin pages for each one depending on that model's attributes. I'm certainly not asking anyone to write my code here, just looking for some tips on where to go in order to find out more about this sort of metaprogramming.
I am running Ruby on Rails 3 and I have an application that makes use of namespaces in order to handle more "internal concepts". With "internal concepts" I mean that each namespace is used to handle a specific resource of my application. For example a namespace is "users" and it is used to handle user's sessions and authorizations, another is "blogs" and it is used to handle all about posts and comments.
I think this is a "convenient" solution to avoid a lot of problems, but not the best.
At this time my RoR application consists of this file system structure:
# "users" and "blogs" are namespaces
RAILS_ROOT/app/controllers/users
RAILS_ROOT/app/controllers/blogs
RAILS_ROOT/app/models/users
RAILS_ROOT/app/models/blogs
RAILS_ROOT/app/views/users
RAILS_ROOT/app/views/blogs
...
I would like to switch the "users" and "blogs" namespace in two RoR applications using subdomains to have something like this:
http://main.com # This is the main RoR application
http://users.main.com # This is another RoR application used to handle users
http://blogs.main.com # This is another RoR application used to handle blogs
In few words, I think I am trying to Scale Out* my application or maybe to create a Webservice for each RoR application, but my issues are:
1. What problems I may encounter?
I noticed of problems about maintaining sessions (in my case I handle those with cookies) between applications but I think it isn't the only one problem.
2. How to handle communication between the three RoR applications in my case?
I noticed that I can use ActiveResource to share information, but I must pay attention to information such as user authentication.
I have to implement the OpenID/Oauth protocol in order to maintain user authentications?
I think I have to ensure the user authentication information with a HTTPS connection also if the comunication is between subdomains. Is it true?
3. How do I organize my work and resources?
With all that being said, I would like to don't use (absolutely) plugins or gems, but, if I need, I would like to implement my own handler.
At the end I would like to have 3 RoR "easy" and separated applications without use namespaces in each of them and that can communicate between each other:
# "Main" application for http://main.com
ROOT_MAIN/app/controllers/
ROOT_MAIN/app/models/
ROOT_MAIN/app/views/users
...
# "Users" application for http://users.main.com
ROOT_USERS/app/controllers/
ROOT_USERS/app/models/
ROOT_USERS/app/views/users
...
# "Blogs" application for http://blogs.main.com
ROOT_BLOGS/app/controllers/
ROOT_BLOGS/app/models/
ROOT_BLOGS/app/views/users
...
BTW: is a good approach the usage of namespaces that I'm doing?
P.S.: If you need some other information, let me know and I will update the question.
*From The O2 Software Process: "Scale Out" refers to the concept of adding more servers to an existing park, as opposed to "Scale Up" which means to replace existing (slow) servers with newer (and faster) servers.
You problem is lot more simpler than you think. It all depends on how you handle your routes.
Ruby On Rails 3 has better support for Subdomains. So, you need not separate them into three/more RoR apps. You can put all your code in one single RoR app. And redirect user.abc.com to any controller like "users/sessions", redirect blog.abc.com to "blogs/blogs" controller. namespaces are convenient in apps like yours where they make your job really quick to separate out contextually different parts of your app in different folders and route formats.
Try the namespaces to your hearts content, I believe you won't get any errors you are imagining right now. I'd suggest you write code for it and come here if you face problems in it.
Is your app really so big that you need to use multiple apps to handle the different concerns? It could be that your post just lacks enough detail to convey the real magnitude of what you are doing but it seems like you are trying to modularize a small enough app that it would be fine without "scaling out" as you say. Or maybe I am just missing something?
I think that is going to be a tricky problem but there may be some way to store session data in the database and either share it the way you handle #2 or you'll have to roll a custom solution for that. I think the biggest problem will be sharing resources across your app, and also if you are breaking user management out into its own app you'll need to implement your own OpenID/Oauth. This post describes this with Devise/OAuth.
You can use activeresource to connect to each app's respective rest api. This post describes one guy's solutions to sharing data across rails apps.
This question is somewhat vague. You described using multiple apps to separate your concerns (blogging vs user management), so I imagine you'll have your resources at the root of each application without any namespacing, as you've done already in your existing application.
Now for a more general response to your entire question, recently I read a blog post regarding Data, Context and Interaction (wikipedia article) on Rails, and I think this might be a better solution for what you are trying to accomplish if you feel like your app is getting out of control.
Sorry for answering this late.
Actually if you want to scale your rails application you need not create different apps for each unit(I mean as you are trying to separate out users and blogs here), you are jumping a step ahead in the process of scaling your app you should first put all individual units as mountable engines and require them as gem in your core application and mount them in your core app routes.As in your case blogs can be moved to a separate mountable engine.If in future you require to scale more then you can move futher to use engines as separate application.Here's a link to a video that may give you idea what I am trying to explain here https://www.youtube.com/watch?v=pm94BsoMGik
I am running Ruby on Rails 3 and I would like to create an application APP1 that acts as a Web Service. Then create another RoR application APP2 that can communicate (send/get information) with APP1 using the OAuth protocol.
What I have to do to start (I am not expert about programming in those topics but I read a lot and I know how they conceptually\theoretically works)? Is it good to think to implement my custom code or maybe it is better to use plugin or gem? Why?
If it is possible, can you write a TODO list and steps to accomplish what I aim?
And, more important, can you suggest me some useful (awesome) resources (like books, blog posts, ...) about creating RoR Web Services?
Assuming you get to decide what kind of Web Service you want, and a RESTful XML Web Service is an acceptable choice, then Rails applications practically do this by default. When you generate scaffolding code, your controller will actually be ready to interface with as a RESTful Web Service.
Of course, that's not everything you need to know and do, but the subject seems to be covered very well by the following series of articles...
http://css.dzone.com/news/rest-with-rails-part-1
http://css.dzone.com/news/rest-with-rails-part-2-serving
http://css.dzone.com/news/rest-with-rails-part-iii-using
Unfortunately, there seem to be some JavaScript errors on those pages, but they're still usable.
I know this doesn't answer the OAuth part of your question, but this article ( http://stakeventures.com/articles/2009/07/21/consuming-oauth-intelligently-in-rails ) apears to have some useful information on that subject. Note that the info here is slightly out of date if you'll be using Rails 3 because you'll want to list the gems in your Gemfile and run bundle install rather than adding config.gem ... lines to your environment.rb file.