Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Admin helpers that reference the login_page setting should be aware of the app's mounted path #1493
It seems that the path applied to login_page is being treated as absolute. The Admin's authentication helpers may redirect to invalid paths when an Admin app (or an app which makes use of Admin helpers) is mounted to a different path than expected. This is more of a problem when the app is loaded as a gem, because it negates the gem user's flexibility in choosing a path appropriate to their app. It would be nice if the path were treated similarly to url_for, which seems to be aware of the app's mounted path.
I've been looking for decent work-arounds to keep me going until this is fixed, so any suggestions would be appreciated.
My current workaround is to set login_page within the controller that manages login, and use url_for to generate it. This placement is due to the router not yet having processed controller paths when app.rb is loaded.
Kludgy, but it seems to work, for now.
hi @phobetron check this. in admin folder the app.rb change this line.
set :login_page, '/admin/sessions/new'
set :login_page, '/sessions/new'
and add this
set :public_folder, Padrino.root('public', 'admin')
this example working for this url
sorry my english :)
No, @angelbotto, that doesn't solve it. Referencing the the mounted path anywhere in the app.rb is not acceptable. That is the core of this issue. This is an actual bug in the padrino-admin code that needs to be addressed.
Besides, plugging it into the public folder path seems hackish. The workaround I posted works under the aforementioned requirement, and it doesn't exploit any padrino quirks.
Thanks @angelbotto for your comments, would you remember at around when we has that chat? What I'm after is the IRC log :).
@phobetron you're right, that is a hack and it's a temporary solution only, that's why I mentioned above that we need to fix that on the framework itself.
However, @angelbotto's recommendation should get you going for now as your workaround does.
I'll look at this in more depth as soon as I can but I don't think I'll have time before mid December if anything.