[Radiant] only_allow_access_to declaration is not inherited in controller subclasses
Using Radiant 0.9.1, Ruby 1.8.7, Apache + mod_passenger in development
environment (for now).
I'm writing a simple extension, where I have a base controller class
that goes like this:
class Admin::BaseController ApplicationController
# allow only admins to the actions in this controller
only_allow_access_to :index, :show, :new, :create, :edit, :update, :remove,
:destroy,
:when = :admin,
:denied_url = { :controller = '/admin/pages', :action =
'index' },
:denied_message = 'You must have administrative privileges to
perform this action.'
# using inherited resources
inherit_resources
# common controller code
...
end
And a bunch of controllers that manage contacts, etc.
class Admin::ContactsController Admin::BaseController
end
But when a non-admin attempts to access this controller access is
granted but shouldn't be. It appears that only_allow_access_to method
call does not get inherited into Admin::ContactsController or any
other controller that inherits from Admin::BaseController . Why? What
am I missing?
I can copy/paste the call to only_allow_access_to for each controller,
but it seems not very DRY.
Having Googled this issue, I found no explanation and ran into a
single msg in this group but no replies.
Would anyone be able to explain why call to only_allow_access_to isn't
being inherited?
Thanks!
[Radiant] Registering observers in a radiant extension
Is there a better way to register an observer for a Radiant extension than editing environment.rb? I have tried adding extension_config block to my extension like so extension_config do |config| config.active_record.observers = :mymodel_observer end But that did not work.
[Radiant] Re: Faster ways to (re)generate sitemap
Unfortunately the site does change, almost on a daily basis. The site averages about 5 new pages per week. On Feb 12, 6:02 am, Mohit Sindhwani t...@onghu.com wrote: On 11/2/2011 10:23 PM, swartz wrote: If the site doesn't change too frequently and is managed by a very small number of people, it may be worthwhile to generate the sitemap and then use it as a static page. Don't render it on demand - just use the static version - when the site changes, access the dynamic sitemap page again to create the new sitemap and use the output to update the static page. It's not pretty, but it works.
[Radiant] Re: Faster ways to (re)generate sitemap
On Feb 11, 10:49 am, Anton J Aylward radi...@antonaylward.com wrote: r:children:each order=asc r:unless_content part=no-map li r:link / /li r:if_children ul r:snippet name=sitemapper / /ul /r:if_children /li /r:unless_content /r:children:each Yes, its still recursive, there no way round that for a general algorithm. Perhaps children:each is faster than nav I tried the above code and did some apachebench tests with cache busting. Doing this yields marginally better result. Not by much. I suspect a lot of your time is because the site is deeply nested. I checked the content structure. We have at most 4 levels of page hierarchy, including the homepage Homepage -- Level 2 Level 3 -- Level 4 -- Level 4 Level 3 -- Level 2 I wouldn't consider this very deep. In any case, so far my ideas to improve the performance: A) Write an extension that will load just the necessary attributes (page title, slug, and position) from the whole page result set (minus no-map pages). Then process the in-memory result set instead of recursively expensive database calls for each page's children. Shouldn't cost too much memory usage even with 10k pages. B) Write an extension that will force sitemap cache to be rebuilt every time a page is modified and is not a 'no-map'. Any other ideas?
[Radiant] Faster ways to (re)generate sitemap
I recently took over support for a large website that uses Radiant. Over 1000 pages and added/edited all the time. The site has a sitemap page, which shows all of the available resources. The sitemap is generated using the navigation_tags extension: r:nav root=/ depth=4 expand_all=true / It takes forever (~25sec) to generate that one page due to the recursive nature of the calls. Are there any faster alternatives to this extension? Open to any suggestions...
[Radiant] Re: render_radiant
I gave a very brief look at your extension.
I do not mean to devalue your contribution(in fact, thank you for it),
but isn't this what share_layout extension does?
https://github.com/radiant/radiant-share-layouts-extension
Also check spanner's fork:
https://github.com/spanner/radiant-share-layouts-extension
--
Swartz
On Jan 19, 9:18 pm, nx n...@nu-ex.com wrote:
I wanted to use ActionController like I always have, except render the
action with Radiant. So I wrote a gem that overrides render to take
instance variables and methods like params and flash from the
action and assign them to the page context to be accessible from my
Radius tags. It uses a Radiant page that matches the URL of the
request for rendering. Here's an example from the README:
EventsController ActionController::Base
def index
@events = Event.all
render :radiant
end
def show
@event = Event.find(params[:id])
render :radiant, :locals = { :cool_event = @event.cool? }
end
end
So a request for /events/23 will use a Page with the url
/events/show and will load tag.locals.event and
tag.locals.cool_event with the values given in the action.
You can override default page properties by passing them into the main
:radiant option:
render :radiant = { :title = Title Override, :breadcrumb = My Page }
This gem also opens up the possibility of handling different formats, like:
respond_to do |format|
format.html { render :radiant }
format.json { render :json }
end
Just do gem install render_radiant and require it in your
extension_config to install. Github:http://github.com/nuex/render_radiant.
Thought someone else might be interested in building custom extensions this
way.
[Radiant] Re: How can i deploy radiant application to sub-directory?
What you've discovered is unfortunately one of Radiant's shortcomings. Radiant expects to be deployed at the root of your particular domain. If you want to deploy it into a subdirectory, there is no easy way. You gonna have to update a lot of files to point to the new subdirectory (things like css, js, and many others). It's not hard, just time consuming and error prone. My recommendation: If you can, deploy radiant to a subdomain instead of a subdirectory. For example to dictionary.yourdomain.com instead of yourdomain.com/ dictionary -- swartz On Nov 26, 12:35 am, Ahn Byungmo b-...@cec-ltd.co.jp wrote: Hello~ I' m trying to deploy my radiant web application with use sub-directory just like below localhost/ localhost/dictionary so i've tried to search how to deploy in sub directory in everywhere then i got some clues about change config/enviroment.rb to add below line config.action_controller.relative_url_root = /dictionary and it's simply works nevertheless it's not change about public path, it's not that story I mean under public path's image files or css files are stil in that path - public/image.jpg also it has got one more problem that can't be shown files under assets path so when i access to admim page, every css and image files were not be shown but still my site was normal, only have problem in admin page my env is ruby - 1.8.7 radiantcms - 0.9.1 anyone can help me please? Ill thank you in little clue! with Best regards!
[Radiant] Re: Best way to protect pages with custom auth-system?
What I've done so far is to use around_filter with process_page from SiteController. But I find that the login in this overwritten method is expensive as it has to run and hit the database for every page. Just seeing if there're better ways to do this.
[Radiant] Re: Best way to protect pages with custom auth-system?
I'm toying with the idea of caching the permissions, that is load them all up and their permission from table into memory and keep them there. So it doesn't have to hit the database every time. The good thing is there're only 200 pages and not 2,000. On Nov 1, 3:53 pm, swartz netv...@gmail.com wrote: What I've done so far is to use around_filter with process_page from SiteController. But I find that the login in this overwritten method is expensive as it has to run and hit the database for every page. Just seeing if there're better ways to do this.
[Radiant] Re: Hide some page types from page edit form
Hi Jim, Thank you for your suggestions. Forgot to mention using 0.9.1gem. What are the changes that are going to happen in the next release? On Oct 21, 10:23 am, Jim Gay j...@saturnflyer.com wrote: On Wed, Oct 20, 2010 at 5:48 PM, swartz netv...@gmail.com wrote: Anyone know what is the easiest way to hide certain Page Types when in page edit form? I'm primary interested in hiding the ones my client has no use for (all Archive capability) and also to hide one other type that I created and is merely a parent page class with 3 other page types inheriting from it. The way we create pages is changing in the next release. What version of Radiant are you using? You can override the regions of the UI with partials See this linehttp://github.com/radiant/radiant/blob/master/app/views/admin/pages/_... You could create an extension with a partial in app/views/admin/pages/_edit_type.html.haml (or erb) Radiant should load that partial instead of the hard-coded region (I think) -- Jim Gay Saturn Flyer LLChttp://www.saturnflyer.com 571-403-0338
[Radiant] Re: Using Devise as an authentication solution for end users with Radiant
Hey Wes,
Glad you got it working.
I shall be attempting to re-integrate devise into an ongoing project
as I've attempted earlier.
Just a few comments:
Step4: It now makes sense. I was not careful at looking at what gets
called and from where. This is where I gave up on my early attempt.
Thank you!
Step5: You can use radiant_layout to use one of the layouts defined in
radiant cms for your extension. For that you need shared_layouts
extension. This cuts down on the having duplicated code for layout,
which, in my case, remains the same as the main site.
On Oct 16, 5:03 pm, Wes Gamble we...@att.net wrote:
All,
I've spent some time getting Devise working as an authentication system
for my end users, and thought I would share how I got it to work.
1) Because Radiant already has a User model, you have to set up Devise
to use a different model for authentication. So, you should choose a
model name, and use that when you install Devise per the directions.
For the purposes of the rest of this explanation, let's assume that the
model name is CustomUser.
2) Do all of your setup for Devise for CustomUser, including setting up
the devise_for route (devise_for :custom_user, etc.). I set up my
Devise route in my custom extension's routes.rb file.
3) To protect all of the end-user content, you need to call the Devise
authenticate method somewhere as a before_filter on the SiteController
(I'm executing the line below in my custom application extension):
#Use Devise to protect all Radiant-generated end-user content
SiteController.class_eval do
#Don't authenticate CSS or JS requests, as these will do redirects
def devise_authentication
authenticate_custom_user! unless params[:url]
params[:url].is_a?(Array) (params[:url].include?('css') ||
params[:url].include?('js'))
end
prepend_before_filter :devise_authentication
end
4) Once you do this, Devise will be set up to be used to authenticate
against your end-user content. But it won't work, because both Devise
and Radiant inject a method named authenticate directly into the
ApplicationController via module inclusion (luckily, they have different
method signatures, or I would have had a tough time figuring that out).
I attempted to force the segregation of these two authenticate methods
using nothing but fancy metaprogramming to try and change inheritance
hierarchies and what-have-you. Ultimately, I decided that the solution
with the least customization (and thus, easiest to manage over time),
would be to statically bypass the ApplicationController provided by
Radiant in Devise. So...
5) Create a new controller named DeviseController that looks like:
class DeviseController ActionController::Base
layout 'devise'
end
I put mine in my custom extension's app/controllers directory, but you
can put it anywhere as long as it is loaded before any of the Devise stuff.
Also, notice that I built a custom layout for Devise (devise.html.haml)
that looks like my Radiant-managed layout for end-user content.
Yes, that means that changes to the layout within Radiant must be
repeated in this layout file. However, I couldn't figure out a good way
to share the layouts (even using file_based_layout, I would have had
significant duplication to deal with - I decided to go the simplest route).
6) Put a copy of the Devise gem into RAILS_ROOT (or
RADIANT_ROOT)/vendor/gems
7) In vendor/gems/devise/app/controllers, change each of the five 5
Devise controller's class definitions so that they descend from
DeviseController, instead of ApplicationController, like so:
class ConfirmationsController DeviseController
Note that each of the 5 controllers does:
include Devise::Controllers::InternalHelpers
and this is where the conflicting authenticate method comes from. But
now, because there's no more ApplicationController in the hierarchy,
there is no conflict.
8) Unfortunately, the redirect on a sign_out does not redirect back to
the log in page by default (I need to resolve this), so I had to do the
following in my DeviseController:
def after_sign_out_path_for(resource_or_scope)
new_custom_user_session_path
end
CAVEATS:
It is very important that the route file that pulls in the Devise route
executes before you attempt to use any of the Devise custom user
specific helpers. The route configuration is what creates all of the
Devise helpers that are then included in various places. If you cause
any helper files to be included before the Devise route is processed,
none of the custom helper methods will be available.
Wes
P. S. It would be interesting to see if it made sense to use Devise for
all Radiant authentication (e.g. both end users and Radiant users), as
Devise has authentication for different scopes baked in from the start.
[Radiant] Best way to protect pages with custom auth-system?
I have a custom auth-system based on authlogic (based largely on reader extension). I have two roles: regular users and moderators. I also have two extra pages types, one is for moderators only, the other is for either. Whats would be recommended way to require certain user role to access a particular page type? Should I define a custom process() method for each page or is there a better way?
[Radiant] Re: Palmer’s Cocoa Butter Massage Cream for Stretch Marks.
Mmmm... Cocoa Butter Goddamn spammers! On Oct 7, 11:22 pm, Elaine Kintner elainekn...@gmail.com wrote: Stretch marks on the stomach are a pregnant woman's worst nightmare. Stretch marks are usually caused by a rapid stretching of the skin - like during pregnancy or other periods of weight gain. Basically, you get stretch marks when your skin is stretched more than what is considered normal and the tissue fibers in your skin break down. While completely removing stretch marks once you have them may be difficult or impossible, minimizing their appearance is achievable.
[Radiant] Re: Avoid using the same Radiant session with custom auth
Hi Wes, Yeap pretty much. On Oct 5, 6:36 pm, Wes Gamble we...@att.net wrote: So you need to maintain two distinct sessions from one browser? Is that right? W On 10/5/10 6:22 PM, swartz wrote: I have a 0.9.1-based radiant install that uses a custom end-user auth- system. It uses authlogic and based primarily on examples from reader and members extension. I've switched from the default cookie session store to :active_record_store for storing session information. And I've also ran into a problem. Both radiant admin and my custom auth system end up sharing session. Specifically, if I have a user that logs into Radiant admin AND into the custom auth system to view content, the session gets messy. Thing sometimes get REALLY messy (wrong redirects, etc). Any way to separate session storage into different table instead of one common one?
[Radiant] Re: undefined method `match' - when testing extension features with cucumber and webrat
I had a similar issue when I was moving extensions from dev-server to production. One of the issues was that I had a typo in the migration scripts and one of the table fields was misnamed when migration was executed. So when I attempted to retrieve data from it, it had that same error regarding match method. Another issue I ran into is when in one of my models (Subscriber) I specifically refer to another model (like Role.all) either through a conditions hash in a named_scope or via a custom validation rule. Just my experience. Check the lines from your code that the error log refers to. That should give you a good idea what went wrong.
[Radiant] Re: Avoid using the same Radiant session with custom auth
Hi Wes,
In fact I already do 1) as you propose. Mainly to remember proper
redirects after login and similarly for flash messages etc.
Here's my issue:
In my environment.rb for Radiant I have,
config.action_controller.session = {
:key = '_appname_cms_session',
:secret = 'mysecret'
}
This is where Radiant stores it's session for things like admin-side
logins. And the cookie path is set for /, but shouldn't it be for /
admin by default ??? I think sending admin-side cookie to all Radiant
requests is a bad idea and should be limited to /admin path.
But I digress...
My custom auth system uses authlogic, which creates it's own cookie as
subscriber_credentials when user successfully logs in (since its
authlogic default naming convention in form of modelname_credentials).
However the two auth-sessions are actually linked to a single session,
since deleting the subscriber_credentials cookie in the browser has no
effect and it gets recreated next time you refresh a page that
requires a logged in user.
Whereas deleting the Radiant cookie _appname_cms_session, I get logged
out (from both admin and custom auth or from either depending where I
had sessions open).
The issue, of course, that there is only one true session that gets
initialized and if I destroy it I get logged out from both admin and
custom auth side.
On Oct 6, 9:38 am, Wes Gamble we...@att.net wrote:
Hmmm...
Some thoughts:
1) You could maintain multiple independent sessions logically by simply
establishing some naming convention of session key values in the one
session. All admin session keys are session[:admin_xxx] and all
regular session keys are session[:regular_xxx]. You could enforce
this fairly easily with a couple of wrapper functions and the discipline
to never access the session directly.
2) You could also embed one session inside the standard session object
by simply establishing a session key of inner_session (or
admin_session or whatever). This would likely require you to decide
which session the top-level keys represented and which the inner key
was responsible for. Same as #1, just not flat.
3) You could maintain a Session AR object independent of the session
object. Similarly, if you were using cookie based sessions, you could
always just maintain a completely separate cookie that you manage by hand.
4) You could always force a logout from one auth. system when the user
logs in to the other, assuming that both logins don't need to be active
at the same time.
W
On 10/6/10 10:26 AM, swartz wrote:
Hi Wes,
Yeap pretty much.
On Oct 5, 6:36 pm, Wes Gamblewe...@att.net wrote:
So you need to maintain two distinct sessions from one browser? Is
that right?
W
On 10/5/10 6:22 PM, swartz wrote:
I have a 0.9.1-based radiant install that uses a custom end-user auth-
system. It uses authlogic and based primarily on examples from reader
and members extension.
I've switched from the default cookie session store
to :active_record_store for storing session information.
And I've also ran into a problem. Both radiant admin and my custom
auth system end up sharing session. Specifically, if I have a user
that logs into Radiant admin AND into the custom auth system to view
content, the session gets messy. Thing sometimes get REALLY messy
(wrong redirects, etc).
Any way to separate session storage into different table instead of
one common one?
[Radiant] Re: Using devise (or some other authentication/authorization framework) as a log in solution for Radiant end-users
Hi Wes, I've ran into a similar issue/problem. Radiant is great and all, except for when it comes down to end-user auth stuff. I wish it was like Drupal's ACL in this respect. As per Jim's remarks, avoid option a). Since Radiant development is a moving target, you may end up with auth system that will not work with future releases. Tried it, didn't like this approach. I was involved in a project(can't speak of details), which required delivering customized content. I originally tried devise, which I've used in projects that are not Radiant-based and loved it. After spending a few days with it I was unable to make it work with Radiant so I gave up. Wes, I think we had an email convo about this. Luckily the requirements and the types of users needed for the project were simple enough that I was able to use authlogic along with examples from existing extensions (reader in particular, thank you spanner) to come up with a working system. However, this was an ugly ugly auth system. I also prefer using a separate table for end-users (e.g. members or subscribers) to keep site admins/editors away from content-consumers as much as possible so as to avoid accidental permission escalation. I think having a standard auth system for content-consumers is a must have for any great CMS. One that supports ACLs or roles would be even better. I certainly hope that Radiant gets one soon. I'd be interested in collaboration to develop such a system. Would love to get more insight from the core Radiant developers on this topic. -- swartz On Oct 5, 11:28 am, Wes Gamble we...@att.net wrote: All, I am wanting to build a fairly full featured login/registration system for my Radiant end-users (content consumers, not authors or reviewers). Obviously, Radiant does come with a built-in authentication/authorization system for administrative users. I am trying to decide between exposing the existing Radiant auth system to end-users (and possibly) customizing it, or using something like devise, which gives me much richer functionality. I'd be interested in hearing about anyone's experience with either: a) using the built-in Radiant lib/login_system to manage end users or b) using something else and challenges faced by using that something else alongside Radiant. Many thanks, Wes
[Radiant] Re: Using devise for a radiant extension
Hmmm... the issue with uninitialized constant SessionsController i was able to resolve by moving gem.config warden gem.config devise to environment.rb instead of the standard extension config block file. Strange... but ok. Now the issue I'm attempting to resolve is as follows: When I attempt to access one of the pages requiring authentication (via devise), I get redirected to /admin/login. That is the radiant admin authentication page. I made sure that no_login_required line is present in my controller to avoid requiring logged-in radiant user.
