Егор Марчук: только это уже специальный вид разметки получается - с метаданными. А не текстовый файл. А их уже немало. Что до ОС (кстати, тут ведь дело в файловой системе, а не ОС) - как по мне - нелогично на уровне ОС делить файлы не тестовые и бинарные (а для последних этот аттрибут не имеет смысла).
PeroPero: Ну так вам и сказано - для начала - школьная программа (ЕМНИП, интегрирование/дифференцирование и прочие пределы с тригонометрией тут понадобятся - но я не сильно вчитывался). А с новым бекграундом уже можно попробовать осилить необходимые тем из "цифровой обработки сигналов" и ИНС :-)
kpa6uu : чего-то я, кстати, не вижу здесь дискретки (точнее - не на поверхности :-) ). Совсем школьная математика - да, ЦОС опять же, и прочие численные методы (ну это раз уж речь прошло о обучении ИНС :-) )
Для начала - какого рода "смысловые части"? Если речь о относительно слабо связанных друг с другом блоках (читай - набор сущностей в одном блоке слабо перекликается с другими)?
А смысл передавать хеш, а не считать его на серверной стороне? Для сравнения :
1. храним в БД хеш. Получаем пароль, хешируем и сравниваем на серверной стороне. Если произошла утечка - ещё нужно подобрать пароли, подходящие к этим хешам. Если как-то утёк переданный пароль - можем авторизоваться сразу.
2. храним хеш. Но получаем его от клиента и сравниваем без дополнительных преобразований. Произошла утечка - авторизоваться можно сразу. Если как-то утёк переданный хеш - можем авторизоваться сразу.
3. храним пароль. Также можно авторизоваться сразу. Если как-то утёк переданный пароль - можем авторизоваться сразу.
То есть непонятно, чем вариант 2 лучше варианта 3 и (главное) в чём его плюс перед 1? Ну и опять же - теперь это хеширование в 2 местах (на стороне клиента и WP) и любые изменения в 1 потребуют вмешательства во второе.
John Smith: Впрочем, на твоём месте я бы таки поднял вопрос на stackoverflow или ru.stackoverflow. Ну и попросил бы раскритиковать мой метод - вдруг укажут, где конкретно я ошибаюсь.
John Smith: может речь шла о чём-то более продвинутом, чем простое хеширование? Всё же отправлять хеш и принимать его на серверной стороне без дополнительных преобразований - по идее ещё опаснее, чем передавать пароль и сравнивать его
John Smith: а пойнт с хешами же - в хранении. Грубо говоря, если утекла БД с хешами, но наше приложение для авторизации получает с клиентской стороны именно пароль (а не хеш) и уже на своей стороне его преобразует и сравнит с хешем - то авторизоваться это не сильно поможет.
John Smith: А в нашем случае - нет разницы. Если мы как-то получили тело POST-запроса (читай - вскрыли сеанс обмена по https) - то хоть мы передаём хеш, хоть пароль - мы можем подделать такой же запрос и wp на принимающей стороне его схавает. Если не прав - поправь. А если прав - зачем выбирать более сложное решение?
