Символьные ссылки на глобальные переменные внутри функции/метода

[Baton]

Здравствуйте, уважаемые!

Возникла потребность получить доступ к суперглобальным переменным с помощью символьной ссылки внутри функции. Но что-то пошло не так:

function f(){
   echo isset( ${ '_'.$_SERVER[ 'REQUEST_METHOD' ] } ) ? 1 : 0; //0
}
f();

Проверим выражение из функции скопировав его в глобальную область видимости:

echo isset( ${ '_'.$_SERVER[ 'REQUEST_METHOD' ] } ) ? 1 : 0; //1

Работает!

А может $_SERVER[ 'REQUEST_METHOD' ] чем-то не угодил? Проверим без него, жестко прописав имена суперглобальных переменных:

function f(){
   $name = '_GET';
   echo isset( $$name ) ? 1 : 0; //0
   $name = '_POST';
   echo isset( $$name ) ? 1 : 0; //0
   $name = '_COOKIE';
   echo isset( $$name ) ? 1 : 0; //0
}
f();
$name = '_GET';
echo isset( $$name ) ? 1 : 0; //1
$name = '_POST';
echo isset( $$name ) ? 1 : 0; //1
$name = '_COOKIE';
echo isset( $$name ) ? 1 : 0; //1

Выходит, что внутри функции ( или метода ) не получается символьно получить доступ к суперглобальным переменным, тогда как в глобальной области видимости проблемы не наблюдается.

Это баг или фишка?

 

[Фанат]

Возникла потребность получить доступ к суперглобальным переменным с помощью символьной ссылки

Блин, ну почему нету кнопки "Мне не нравится"?

 

[Вурдалак]

http://ru2.php.net/manual/en/language.variables.variable.php

Please note that variable variables cannot be used with PHP's Superglobal arrays within functions or class methods.

Variable variables вообще не нужно использовать ни при каких обстоятельствах.

 

[Активист]

getenv, apache_getenv

 

[Вурдалак]

getenv

vprintf

 

[Духовность™]

ммм... а зачем для суперглобалса нужна ссылка? Она же по факту является ссылкой или нет?

 

[Baton]

Вурдалак

Please note that variable variables cannot be used with PHP's Superglobal arrays within functions or class methods.

Благодарю за это! Значит фишка.

Ну а почему бы не использовать символьную ссылку. Бояться подделки? Можно и проверку влепить на всякий случай:

if( !in_array( $_SERVER[ 'REQUEST_METHOD' ], array( 'GET', 'POST' ) ) ) die;

На сервере заранее не известно каким методом придут данные. Но после того как данные получены, в самих данных есть имя элемента на котором сработало событие и есть возможность проверить какой метод был задан для данного элемента. Если для элемента был указан POST а данные пришли в GET, то запрос сбрасывается.

Что красивее на Ваш взгляд:

Вариант1

function f(){
   $data = ${'_'.$_SERVER[ 'REQUEST_METHOD' ]}[ 'data' ];
}

Вариант2

function f(){
   $data = isset( $_POST[ 'data' ] ) ? $_POST[ 'data' ] : ( isset( $_GET[ 'data' ] ) ? $_GET[ 'data' ] : '' );
}

 

[fixxxer]

Вариант 3
$data = isset($_REQUEST['data']) ? $_REQUEST['data'] : '';

 

[Baton]

fixxxer

Не надежно, т.к. "?data=123..." может быть в GET и в POST, хотя признаю, что ситуация слишком гипотетическая.

 

[Вурдалак]

Baton, может, конечно. Но тут встаёт вопрос: а кого это волнует? Единственное, я где-то видел уязвимость, связанную с тем, что данные брались из разных источников: из $_POST и $_REQUEST при проверке и записи, надо быть осторожнее.

 

[fixxxer]

fixxxer

Не надежно, т.к. "?data=123..." может быть в GET и в POST, хотя признаю, что ситуация слишком гипотетическая.

Может. И в чем отличие от твоих вариантов?

 

[Baton]

Не нравится мне $_REQUEST, имхо рано или поздно будет запилен.

Я тут немного ввел в заблуждение, код выглядит так:

function f(){
   $data = isset( $_POST[ 'data' ] ) ? $_POST : ( isset( $_GET[ 'data' ] ) ? $_GET : '' );
}

$_REQUEST в моей ситуации не подойдет, т.к. это фактически превратится в $data = isset($_REQUEST['data']) ? $_REQUEST : '';

 

[Фанат]

Тяжела и неказиста жизнь у велосипедиста...

 

[Baton]

Вам не виднее.

 

[Beavis]

Какая тебе разница через GET или через POST пришли данные? При желании их можно отправить через что угодно. Так что используй $_REQUEST и не изобретай непонятно что