Факт - это то что случилось или то что точно случится. Если брать горизонт планирования на много тысяч или миллионов лет, наверно да, это почти неизбежно.
Если рассуждать на менее масштабных сроках - вообще не факт. Каких-то 50 лет назад, при намного меньшей численности населения Земли, основным страхом было перенаселение. То, что после взрывного роста населения наблюдается некоторое сокращение - не выглядит чем-то экстраординарным.
Переменные, о которых идёт речь в статье: это часть строки запроса. Например, var1 и var2 в этом HTTP GET запросе:
https://example.com/items/var1/data?param2=var2
Но надо отметить, что есть общая рекомендация не передавать в path-сегментах (как var1) или query-параметрах (как var2) никакие чувствительные данные, даже при использовании HTTPS (а в этом случае все эти данные не передаются в открытом виде). И причины такой рекомендации - именно такие, что где-то по пути строка запроса может оказаться залогированной, например в логах веб-сервера.
Если нужно передавать чувствительные данные в запросе (например, токен авторизации), более предпочтительно их передавать в заголовках запроса, например так:
GET http://example.com/ HTTP/1.1
Host: decimalparser.net
Authorization: Bearer eyJbWbfs...
Postman - инструмент для создания, редактирования и выполнения HTTP запросов.
Штука довольно удобная - можно настраивать заголовки, тело запроса, изучать ответ сервера. Мне нравится тем, что можно создавать коллекции запросов (и даже сохранять примеры ответа от сервера на будущее, чтобы потом в оффлайне их изучать).
Ещё для выбранного запроса можно сразу получить сгенерированный код на одном из языков программирования (например C#). Можно настроить mock-сервер для тестирования веб-хуков (когда тестируемое приложение само отправляет запрос на стороннее API, которое нежелательно использовать при тестировании). Да и много других фичей.
Всё-таки новость кажется несколько преувеличенной. Мельком в статье упоминается, что секреты из заголовков не отправляются в логи. В логах могут встретиться только те данные, которые были отправлены в сегментах URL или в query параметрах. Но и для тех и для других есть общая рекомендация не использовать для чувствительных данных - именно потому, что высока вероятность, что они осядут в логах где-то "по дороге". И хотя при использовании https эти данные не передаются в открытом виде, они легко могут оказаться например в логах веб-сервера. Вот статья об этом https://blog.httpwatch.com/2009/02/20/how-secure-are-query-strings-over-https/
Так что имхо, автор сам стреляет себе в ногу и жалуется на последствия. Хотя лично я не одобряю, что множество данных отправляется на неизвестные сервера, конкретно эта претензия выглядит надуманной.
Кстати у себя тоже такое наблюдаю - иногда захожу в комментарии, и с удивлением вижу негодование по поводу ссылки на телегу, и думаю: "Ребята, а как Вы вообще её заметили?"
Автор, расскажите пожалуйста об упомянутом "правиле верхней трети шкалы". В гугле при поиске по этой фразе в кавычках результат только один - эта статья.
Если читаете через браузер на десктопе - выделяете фрагмент и по Ctrl-Enter отправляете сообщение об опечатке (фактически обычное личное сообщение, но со ссылкой на статью). Полагаю имелось в виду это.
Согласен, и дополню: этот условный Вася, если подвесил таким образом гирю, представляет общественную опасность.
Предположим, из его квартиры повалил дым/прорвало трубу/кто-то вызвал врачей, ошибившись, на его адрес. В итоге пострадает не злоумышленник, а вполне себе добросовестный слесарь/врач/полицейский.
Не соглашусь. Помню что промучавшись какое-то время, всё-таки получается дойти до решения. Если правильно понмю, нужно было просто прокликать все ручки, которые в исходном состоянии были в "неправильном" положении (именно в исходном состоянии, то есть надо запомнить нужные ручки).
Да, похоже я ошибся: они объявили что прекращают развитие .net framework, но будут продолжать его поддержку в виде багфиксов и т.п. То есть именно deprecated его не объявляли.
С ldap можно и под линуксом работать. Но в любом случае, это довольно специфические задачи. В настоящее время большинство веб-сервисов, написанных на asp.net, крутятся на линуксе.
И это логично, ведь число в двоичной системе делится на 4, если два последних разряда - это нули. Моя ошибка. Впрочем, сути это не меняет - проверять только по признаку делимости на 4 намного легче, чем дополнительно по признакам делимости на 100 и на 400.
Её не "обнаружили", а сознательно добавили, для совместимости с более древним Lotus 123, где в свою очередь реализовали таким образом из-за того, что проверка через делимость на 4 (для чего нужно просто сравнить один бит) технически была предпочтительнее, перед его разработчиками стояли очень жёсткие технические ограничения
“So, it’s a bug in Lotus 123?”
“Yeah, but probably an intentional one. Lotus had to fit in 640K. That’s not a lot of memory. If you ignore 1900, you can figure out if a given year is a leap year just by looking to see if the rightmost two bits are zero. That’s really fast and easy. The Lotus guys probably figured it didn’t matter to be wrong for those two months way in the past. It looks like the Basic guys wanted to be anal about those two months, so they moved the epoch one day back.”
Автор, пожалуйста сжимайте картинки перед там как вставлять их в статью. Если каждая картинка весит больше 1 МБ, чтение статьи становится неудобным
Факт - это то что случилось или то что точно случится. Если брать горизонт планирования на много тысяч или миллионов лет, наверно да, это почти неизбежно.
Если рассуждать на менее масштабных сроках - вообще не факт. Каких-то 50 лет назад, при намного меньшей численности населения Земли, основным страхом было перенаселение. То, что после взрывного роста населения наблюдается некоторое сокращение - не выглядит чем-то экстраординарным.
Пока что такие панические реплики про вымирание напоминают обсуждение оптовых поставок свадебных тортов любителям экстраполировать.
Практика показывает, что не все и не всегда обращают на это внимание.
С интересом прочитал, жду продолжения!
Нет, в ASCII буквы идут по алфавиту. Но удачно получилось, что все гласные на нечётных позициях
Так что самый младший бит всегда 1. Дальше можно смотреть на пятый с конца бит, который для всех кроме U равен 0.
Переменные, о которых идёт речь в статье: это часть строки запроса. Например, var1 и var2 в этом HTTP GET запросе:
https://example.com/items/var1/data?param2=var2Но надо отметить, что есть общая рекомендация не передавать в path-сегментах (как var1) или query-параметрах (как var2) никакие чувствительные данные, даже при использовании HTTPS (а в этом случае все эти данные не передаются в открытом виде). И причины такой рекомендации - именно такие, что где-то по пути строка запроса может оказаться залогированной, например в логах веб-сервера.
Если нужно передавать чувствительные данные в запросе (например, токен авторизации), более предпочтительно их передавать в заголовках запроса, например так:
Postman - инструмент для создания, редактирования и выполнения HTTP запросов.
Штука довольно удобная - можно настраивать заголовки, тело запроса, изучать ответ сервера. Мне нравится тем, что можно создавать коллекции запросов (и даже сохранять примеры ответа от сервера на будущее, чтобы потом в оффлайне их изучать).
Ещё для выбранного запроса можно сразу получить сгенерированный код на одном из языков программирования (например C#). Можно настроить mock-сервер для тестирования веб-хуков (когда тестируемое приложение само отправляет запрос на стороннее API, которое нежелательно использовать при тестировании). Да и много других фичей.
Интерфейс Postman
Всё-таки новость кажется несколько преувеличенной. Мельком в статье упоминается, что секреты из заголовков не отправляются в логи. В логах могут встретиться только те данные, которые были отправлены в сегментах URL или в query параметрах. Но и для тех и для других есть общая рекомендация не использовать для чувствительных данных - именно потому, что высока вероятность, что они осядут в логах где-то "по дороге". И хотя при использовании https эти данные не передаются в открытом виде, они легко могут оказаться например в логах веб-сервера. Вот статья об этом https://blog.httpwatch.com/2009/02/20/how-secure-are-query-strings-over-https/
Так что имхо, автор сам стреляет себе в ногу и жалуется на последствия. Хотя лично я не одобряю, что множество данных отправляется на неизвестные сервера, конкретно эта претензия выглядит надуманной.
Кстати у себя тоже такое наблюдаю - иногда захожу в комментарии, и с удивлением вижу негодование по поводу ссылки на телегу, и думаю: "Ребята, а как Вы вообще её заметили?"
Давайте немного переформулируем вопрос:
Автор, расскажите пожалуйста об упомянутом "правиле верхней трети шкалы". В гугле при поиске по этой фразе в кавычках результат только один - эта статья.
Если читаете через браузер на десктопе - выделяете фрагмент и по Ctrl-Enter отправляете сообщение об опечатке (фактически обычное личное сообщение, но со ссылкой на статью). Полагаю имелось в виду это.
Мне кажется, многие такие сочетания я обнаруживал просто методом "тыка"
Согласен, и дополню: этот условный Вася, если подвесил таким образом гирю, представляет общественную опасность.
Предположим, из его квартиры повалил дым/прорвало трубу/кто-то вызвал врачей, ошибившись, на его адрес. В итоге пострадает не злоумышленник, а вполне себе добросовестный слесарь/врач/полицейский.
Не соглашусь. Помню что промучавшись какое-то время, всё-таки получается дойти до решения. Если правильно понмю, нужно было просто прокликать все ручки, которые в исходном состоянии были в "неправильном" положении (именно в исходном состоянии, то есть надо запомнить нужные ручки).
Да, похоже я ошибся: они объявили что прекращают развитие .net framework, но будут продолжать его поддержку в виде багфиксов и т.п. То есть именно deprecated его не объявляли.
Вот эта новость https://devblogs.microsoft.com/dotnet/net-core-is-the-future-of-net/
С ldap можно и под линуксом работать. Но в любом случае, это довольно специфические задачи. В настоящее время большинство веб-сервисов, написанных на asp.net, крутятся на линуксе.
И это логично, ведь число в двоичной системе делится на 4, если два последних разряда - это нули. Моя ошибка. Впрочем, сути это не меняет - проверять только по признаку делимости на 4 намного легче, чем дополнительно по признакам делимости на 100 и на 400.
Мне понравилось вот это видео, довольно подробно и доступно разбираются основы кубера
https://www.youtube.com/watch?app=desktop&v=X48VuDVv0do
Её не "обнаружили", а сознательно добавили, для совместимости с более древним Lotus 123, где в свою очередь реализовали таким образом из-за того, что проверка через делимость на 4 (для чего нужно просто сравнить один бит) технически была предпочтительнее, перед его разработчиками стояли очень жёсткие технические ограничения