Когда методы API отмечены “удержанные от использования” на самом деле попытка уйти?

Внимание: примерный код этого ответа (например, примерный код вопроса) использует расширение PHP mysql, которое устарело в PHP 5.5.0 и полностью удалено в PHP 7.0.0.

Если вы используете последнюю версию PHP, опция mysql_real_escape_string, описанная ниже, больше не будет доступна (хотя mysqli::escape_string является современным эквивалентом). В настоящее время опция mysql_real_escape_string имеет смысл только для устаревшего кода на старой версии PHP.


У вас есть два варианта - экранирование специальных символов в вашем unsafe_variable или использование параметризованный запрос. Оба будут защищать вас от SQL-инъекций. Параметрированный запрос считается лучшей практикой, но для его использования потребуется переходить на более новое расширение mysql в PHP.

Мы рассмотрим нижнюю строку удара, которая будет первой.

//Connect

$unsafe_variable = $_POST["user-input"];
$safe_variable = mysql_real_escape_string($unsafe_variable);

mysql_query("INSERT INTO table (column) VALUES ('" . $safe_variable . "')");

//Disconnect

См. также информацию о функции mysql_real_escape_string .

Чтобы использовать параметризованный запрос, вам нужно использовать MySQLi , а не функции MySQL . Чтобы переписать ваш пример, нам понадобится что-то вроде следующего.

prepare("INSERT INTO table (column) VALUES (?)");

    // TODO check that $stmt creation succeeded

    // "s" means the database expects a string
    $stmt->bind_param("s", $unsafe_variable);

    $stmt->execute();

    $stmt->close();

    $mysqli->close();
?>

Ключевая функция, которую вы хотите прочитать, будет mysqli::prepare .

Также, как предложили другие, вы можете сочтет полезным / легче повысить уровень абстракции с помощью чего-то вроде PDO .

Обратите внимание, что случай вы спросили об этом довольно просто, и что более сложные случаи могут потребовать более сложных подходов. В частности:

  • Если вы хотите изменить структуру SQL на основе пользовательского ввода, параметризованные запросы не помогут, и требуемое экранирование не распространяется на mysql_real_escape_string. В этом случае вам лучше было бы пропускать вход пользователя через белый список, чтобы обеспечить доступ только «безопасных» значений.
  • Если вы используете целые числа от пользовательского ввода в состоянии и берете mysql_real_escape_string, вы столкнетесь с проблемой, описанной в Polynomial в комментариях ниже. Этот случай более сложный, поскольку целые числа не будут окружены кавычками, поэтому вы можете иметь дело с проверкой того, что пользовательский ввод содержит только цифры.
  • Есть, вероятно, другие случаи, о которых я не знаю. Вы можете найти , этот является полезным ресурсом для некоторых более тонких проблем, с которыми вы можете столкнуться.
25
задан Jens Bannmann 21 May 2018 в 09:24
поделиться

10 ответов

Относительно API... это не определяется, они будут удалены в ближайшее время.

Несовместимости в J2SE 5.0 (начиная с 1.4.2) :

Исходная Совместимость

[...]
В целом, политика следующим образом, за исключением любых несовместимостей, перечисленных далее ниже:

API Устаревшие являются интерфейсами, которые поддерживаются только для назад совместимости. javac компилятор генерирует предупреждающее сообщение каждый раз, когда один из них используется, если-nowarn параметр командной строки не используется. Рекомендуется, чтобы программы были изменены для устранения использования API устаревших, , хотя нет никаких текущих планов удалить такие API †“за исключением JVMDI и JVMPI †“полностью от системы.

Даже в , Как и Когда Удержать от использования API , ничто не говорится о политике относительно на самом деле удаление API устаревшие...

<час>

Обновление 10 лет спустя, новое JDK9 + Расширенная Депрекация разъясняет политику амортизации.
См. Jens Bannmann ответ для получения дополнительной информации.
Это также детализировано в этом сообщении в блоге VojtД ›ch RЕЇЕѕiДЌka, после критические замечания на JEP 277.

соглашение для JDK состоит в том, что, как только API JDK отмечен как forRemoval=true в определенной версии Java, это будет удалено в непосредственно после основного выпуска .
Java, Который означает - когда что-то отмечено как forRemoval=true в Java 9, это, как предполагается, полностью удалено в Java 10.
Имеют это в виду при использовании API, отмеченного для удаления.

Примечание, которое это соглашение применяет только к самому JDK и сторонним библиотекам, является бесплатным выбрать любое соглашение, они считают целесообразным.

25
ответ дан VonC 28 November 2019 в 18:21
поделиться

Они не уходят. Однако они обычно удерживаются от использования, потому что a), они - опасное крыло Thread.stop (), или b) существует лучший или по крайней мере более принятый способ сделать это. Обычно устаревший метод javadoc даст Вам подсказку относительно лучшего пути. В Вашем случае Календарь является рекомендуемым способом сделать это.

, В то время как возможно, что они будут удалены в какой-то момент в будущем, я не держал бы пари на нем. Если кто-либо когда-нибудь будет разветвлять Java однако, они, вероятно, будут первой вещью пойти...

13
ответ дан Alex Miller 28 November 2019 в 18:21
поделиться

Одна проблема, Вы будете видеть много предупреждений компилятора об использовании устаревших методов. Если Вы также будете использовать депрекации для постепенного постепенного выведения собственного кода, предупреждения компилятора потеряются в шуме и потеряют значение.

7
ответ дан Eric Burke 28 November 2019 в 18:21
поделиться

tl; dr

Начиная с JDK 10 , все оригинальные методы java.util.Date все еще существуют, но эти и другие API теперь могут быть явно помечены для удаления , Другие API были недавно удалены.

Полный ответ

До Java 9 ни один устаревший API в JDK никогда не удалялся (см. 20 лет устаревания Java ).

Однако, как часть функции, называемой Enhanced Deprecation , JDK 9 ввел флаг @Deprecated(forRemoval=true) и добавил его к десяткам ранее устаревших API . java.util.Date методы не были среди них, хотя.

Кроме того, впервые в истории языка JDK 9 удалил ранее устаревшие API (как описано в в спецификации Java SE 9 ). Они были препятствием для модульности и были объявлены устаревшими в JDK 8.

В JDK 10 отмечены более устаревшие API для удаления . Еще раз, java.util.Date методы были сэкономлены.

JDK 10 также удалил некоторые устаревшие API для удаления в классах SecurityManager и Runtime (как описано в в спецификации Java SE 10 ).

Итак, выводы:

  1. Устаревшие для удаления API, скорее всего, будут удалены в ближайшее время. Примите это всерьез. Хотя их нельзя удалить в выпуске после маркировки forRemoval (например, Thread.stop(), отмеченной в JDK 9, но оставшейся в JDK 10), это может произойти быстро.
  2. Ни один устаревший API не является безопасным, поскольку даже давно устаревшие API можно было удалить довольно быстро: один выпуск JDK устанавливает флаг forRemoval, а следующий - API. Например, API, которые были удалены с помощью JDK 10, устарели в течение как минимум 20 лет (начиная с JDK 1.2), так долго, что некоторые люди теперь могут быть удивлены.
  3. Благодаря новому 6-месячному циклу выпуска Oracle выпуски JDK и, соответственно, устаревание и удаление происходят гораздо быстрее.
5
ответ дан Jens Bannmann 28 November 2019 в 18:21
поделиться

Ну, "не уведенный все же" и "никогда уходящий" не две совсем других вещи. Это - смысл депрекации. Они могут уйти с любым будущим выпуском. Используя их на Ваш собственный риск суждение. Просто знайте, что некоторый будущий выпуск JDK может оставить Ваш код в неприменимом состоянии.

4
ответ дан Brett McCann 28 November 2019 в 18:21
поделиться

У меня есть лучшая рекомендация: вместо того, чтобы говорить ему использовать Calendar, необходимо переключиться или на JodaTime или на предварительная версия JSR-310 . Некоторые методы на java.util.Date могут быть удержаны от использования, но по-моему целый класс должен быть удержан от использования, наряду с Calendar. Разработчики JSR-310, кажется, соглашаются, хотя я сомневаюсь, что они когда-либо стиснут зубы и удерживать от использования его.

Без определенного порядка, вот что случилось с Date:

  • Его внутреннее представление является миллисекундами с эпохи; поэтому, не может представить даты перед эпохой.

  • Все его полезные методы (например, toString) сначала нормализуют дату согласно локальному часовому поясу. При работе с UTC Date экземпляры, это может стать действительно раздражающим; Вы вынуждены использовать Calendar, или Вы совершите очень плохие ошибки.

  • Calendar. Это просто воняет. Мог бы получить премию за худший API когда-либо.

  • Всегда представляет момент вовремя . Никакой способ представить определенные дни или определенные годы. Никакой способ представить значения дат часового пояса меньше.

  • Не Имеет почти никаких полезных методов. Посмотрите, например, быстрый интерфейс JodaTime для того, чтобы сделать арифметику дат.

  • Должен был быть назван Datetime, полагая, что это - то.

3
ответ дан user38748 28 November 2019 в 18:21
поделиться

Если бы устаревшие методы ушли, они могли бы повредить существующий код.

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

Думают "удержанный от использования" как значение "устаревшего", но не обязательно "на колоде для рубки мяса".

2
ответ дан David Koelle 28 November 2019 в 18:21
поделиться

Функции устаревших функций, которые заменяют и нужно избежать. Хотя они остаются в JDK, им препятствуют, поскольку существуют лучшие доступные методы. Методы оставляют в API поддерживать обратную совместимость, но нужно обычно избегать, поскольку они могли быть удалены в будущих версиях API.

нормально технически использовать устаревшие методы, но обычно причина, это удерживалось от использования во-первых, состояла в том, что был разработан лучший/быстрее/более чистый API.

2
ответ дан Rich Kroll 28 November 2019 в 18:21
поделиться

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

, Но устаревшие методы мог уходить в любое время в будущем и обычно удерживаются от использования по причине - или потому что они ненадежны, потому что у них есть неприятные побочные эффекты, или просто потому что существует лучший или более изящный способ сделать вещи. JavaDoc для метода будет обычно детализировать, какой из них имеет место и что приемлемый способ провести ту же операцию в эти дни. Вполне часто устаревший метод будет заменен реализацией, которая называет 'корректный' метод так или иначе, таким образом, Вы просто добавляете уровень абстракции так или иначе.

у Вас также будет много предупреждений компиляции при использовании этих методов которые могли бы быть причиной достаточно для предотвращения их сам по себе...

1
ответ дан Adrian 28 November 2019 в 18:21
поделиться

Я определенно видел, как устаревшие функции уходят - от старых версий Java до текущей (я начал на 1.1, а некоторые вещи явно НЕ РАБОТАЛИ в 1.4).

Другие языки по-разному относятся к устареванию - в прошлом было известно, что Python, например, удаляет устаревшую функциональность только после выпуска или двух.

1
ответ дан warren 28 November 2019 в 18:21
поделиться
Другие вопросы по тегам:

Похожие вопросы: