Скрыть действия FW/1 без метода контроллера (только просмотр)

Вы можете создать метод в контроллере, который проверяет rc.action, чтобы увидеть, начинается ли часть item с _ и перенаправляет куда-то еще (или выдает ошибку, или что-то еще). Затем вызовите этот метод, используя функцию controller() в вашем методе setupRequest() в Application.cfc.

Например, у меня есть контроллер controllers/security.cfc с методом checkItem() следующим образом:

function checkItem( rc ) {
    //check if restricted item hss been requested and redirect to main.default
    if ( left(variables.fw.getItem(), 1) eq "_" ) {
        variables.fw.redirect('main');
    }
}

И вызовите его в setupRequest() в Application.cfc:

function setupRequest() {
    //controller( 'security.authorize' );
    controller( 'security.checkItem' );
}

Таким образом, он автоматически вызывается при каждом запросе — нет необходимости определять отдельный метод для каждого _item в контроллерах.

Самый простой способ сделать это — поместить их в папку, которая не находится в корневом каталоге. Поэтому они не доступны в Интернете. Затем используйте сопоставление ColdFusion, чтобы сделать их доступными для ColdFusion.

Есть смысл?

Вы можете использовать mod_rewrite для обнаружения URL-адресов, содержащих /_, и блокировки/перенаправления в зависимости от ситуации. .

Например:

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} ^/\w+/_
RewriteRule ^.* /error/404 [L]

Первый RewriteCond гарантирует, что файл не существует, поэтому, если у вас есть настоящий файл, /css/_default.css любые запросы к нему не удовлетворят этому условию и не будут перенаправлены.

Второй RewriteCond принимает любые буквенно-цифровые символы для первого сегмента, а затем продолжает работу, если в начале второго сегмента есть _. (Не обязательно сопоставлять весь URI, достаточно только начала.)

Наконец, RewriteRule применяется, только если оба условия были истинными, но соответствует всем URL-адресам и выполняет перенаправление на стороне сервера на /error/404 — вы можете обновить эту часть по мере необходимости. (Флаг [L] указывает mod_rewrite не предпринимать дальнейших попыток перезаписи.)

Хорошо, так как ответа, которого я ожидал, нет (и это нормально), вот еще один подход, который я уже использую для шаблонов электронной почты.

В /views/emails/ все представления являются шаблонами электронной почты, которые не имеют действий, а вызываются только так:

local.body = variables.fw.view("emails/registration_confirmation", local.attrs);
local.template = variables.fw.view("emails/default", {body = local.body});

Где registration_confirmation.cfm — это шаблон для конкретного тела письма, а default.cfm (можно назвать по-другому) — сам шаблон письма.

Чтобы предотвратить проблему, которую я описал в вопросе, контроллер emails.cfc выглядит так:

component extends="components.helpers.controller" {

    public void function before(required struct rc) {
        variables.fw.redirect("user.forbidden");
    }

}

Думаю, можно было бы создать еще один такой контроллер partials.cfc и хранить все представления в /views/partials/.

Но это мой первый реальный проект FW/1, и я слишком поздно пришел к идее рефакторинга такого количества представлений (1), плюс я думаю, что партиалы в одном каталоге хуже с точки зрения обслуживания, чем их где это имеет смысл для них (2).

Вот две причины, по которым я задал этот вопрос.