Проблема маршрута составного приложения

В своем приложении Pyramid я настроил составное приложение с моим основным приложением на / и порталом администрирования на /admin.

[composite:main]
use = egg:paste#urlmap
/ = mainapp
/admin = adminapp

[app:mainapp]
use = egg:myApp#main

[app:adminapp]
use = egg:myApp#admin

Я также добавил два отдельных метода инициализации в свой метод __init__.py, чтобы иметь две отдельные политики add_request_method и аутентификации — одну для обычных пользователей, а другую для администраторов.

Чтобы проверить это, я добавил два маршрута, один как:

config.add_route('admin_login_handler', '/admin/login/')

для входа в административный портал, а другой как:

config.add_route('login_handler', '/login/')

для общего входа на сайт. Предположительно, я бы увидел два разных шаблона, по одному для каждого представления, и у меня был бы отдельный объект запроса для администраторов и обычных пользователей — self.request.admin для администраторов и self.request.user для пользователей.

Однако, когда я перехожу к /admin/login/, отображается шаблон /login/. По сути, маршруты моего основного приложения теперь расположены как под /, так и под /admin, а мои маршруты администратора игнорируются. Это не то, чего я хотел. Но я получаю желаемый объект self.request.admin при просмотре маршрутов /admin, а объект self.request.user — на маршрутах /, независимо от отображаемого шаблона/представления.

Как я могу это исправить, чтобы маршруты с /admin/... не «пересопоставлялись» с моими маршрутами /, и у меня было два отдельных приложения с двумя разными префиксами маршрутов?


person Friendly King    schedule 14.07.2014    source источник


Ответы (1)


Чтобы исправить эту проблему, я добавил config.scan(ignore="myApp.views.main") к моему методу __init__.admin_app, а также config.scan(ignore="myApp.views.admin") к моему методу __init__.main_app. Обратите внимание на разделение представлений на два файла, чтобы сделать это явным и простым в использовании.

Это разделило два набора маршрутов между двумя приложениями, а затем я смог заставить действовать две мои политики авторизации вместе с моими config.add_request_methods — одна проверяла таблицу admin, а другая проверяла таблицу user — в каждом из соответствующие методы инициализации.

config.add_request_method(AuthHelper.get_user, 'user', reify=True)  # Global user object

а также

config.add_request_method(AuthHelper.get_admin, 'admin', reify=True) # Global admin object

Мои маршруты администратора были сопоставлены с неявным "префиксом маршрута" /admin -- в соответствии с моим файлом .ini.

Пока все хорошо с этой реализацией. Надеюсь, это может помочь кому-то в какой-то момент.

person Friendly King    schedule 14.07.2014