??

ребята, есть необходимость использовать обратимое хеширование в php. Есть строка, которую нужно вначале зашифровать, а потом уже расшифровать без потери содержимого. Что посоветуете использовать?

xor самое простое

openssl

ребята, есть необходимость использовать обратимое хеширование в php. Есть строка, которую нужно вначале зашифровать, а потом уже расшифровать без потери содержимого. Что посоветуете использовать?

зачем?

зачем?

да наткнулся на ограничение количества символов в блокчейне. А в него надо прокинуть серелизованные объекты

да наткнулся на ограничение количества символов в блокчейне. А в него надо прокинуть серелизованные объекты

не надо в блокчейн прокидывать сереиализованные пхп обьекты. блокчейн не должен знать про пхп код.

не надо в блокчейн прокидывать сереиализованные пхп обьекты. блокчейн не должен знать про пхп код.

принцип проекта такой. Без этого никуда

принцип проекта такой. Без этого никуда

придумай другое решение

придумай другое решение

та не получится. Заказы должны храниться в блокчейне, такой принцип проекта.

та не получится. Заказы должны храниться в блокчейне, такой принцип проекта.

заказ это не пхп обьект.

заказ это не пхп обьект.

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

Тут главный вопрос - как компактей запихнуть большую информацию без потерь в строку

Это называется "компрессия"

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

А дальше уже разруливайте, что если хэш из чейна не совпадает с фактическим - алярма

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

rpc, queue, es, saga... нет нам нужен именно blockchain...

rpc, queue, es, saga... нет нам нужен именно blockchain...

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

Вот как есть ?

можно изменить прошлое, будет 2 цепочки просто...

Смысл в этом, но реализаций разных можно напридумывать кучу, никто не запрещает

Можно хранить данные, а можно целый распределенный компьютер запепячить как в эфире

юзай гит - вот тебе и блокчейн ;)

юзай гит - вот тебе и блокчейн ;)

и с ветками )

гит редактируем

Блокчейн тоже, если ты владелец сети ;)

Ребят, здравствуйте всем, подскажите одну вещь: как мне узнать название устройства, телефона ПК php или же как вывести полную статистику устройства

Ребят, здравствуйте всем, подскажите одну вещь: как мне узнать название устройства, телефона ПК php или же как вывести полную статистику устройства

средстами php ничего подобного ты не получишь

А чем можно?

Максимум что ты можешь узнать, это некоторый, крайне малый набор доступный в $_SERVER

На JS можно узнать чуть больше, но опять же, далеко не все

ну почему, юзерагент + база девайсов - можно достаточно много узнать

но на js надежнее, да

ну почему, юзерагент + база девайсов - можно достаточно много узнать

Само устройство, много о себе не расскажет

Просто, при регистрации я хочу записать в бд устройство с которого зареган, и если пользователь в друг забудет пароль, или что-либо, и e-mail я должен удостовериться, точно ли его аккаунт

а базу девайсов еще где-то надо взять, плюс помнится в юзерагент не входит марка и модель девайса

Просто, при регистрации я хочу записать в бд устройство с которого зареган, и если пользователь в друг забудет пароль, или что-либо, и e-mail я должен удостовериться, точно ли его аккаунт

изобретаешь велосипед. возьми fingerprint2.js и храни в его cookie\localstorage и у себя в базе, отпечаток, полученный через него

по нему и сверяй

Да по смотрю про это

Спс

?

Но имхо, юзеры на хромах и ведрах как правило по дефолту используют синхронизацию паролей

че там у айфонов хз, но примерно тоже самое

Просто, при регистрации я хочу записать в бд устройство с которого зареган, и если пользователь в друг забудет пароль, или что-либо, и e-mail я должен удостовериться, точно ли его аккаунт

пользователь забудет свой емейл?

А то такое не бывает?

Вот у меня например 20 e-mail я ж не все помню

Верно?

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

Вот у меня например 20 e-mail я ж не все помню

для этого есть браузер, который помнит твои логин\пасс от ящика и синхронит их на сервер

Потому что забывчивый юзер может также переехать и купить новый телефон, такое не бывает?

А если удалить данные из Гугла, куки в том числе, то все пропадает

И нечего не сохраняется

Когда историю в Гугле удаляешь, там есть галочки вот их все поставь, и не чего у тебя не сохранится

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

ERROR: S client not available

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

Ну проверь, удалить все, а потом скажешь

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

Я вот недавно был в аккаунте у меня все удалилось, когда я очистил

Ну проверь, удалить все, а потом скажешь

Речь шла про удаление данных внутри браузера, а не внутри аккаунта(или его настроек)

Без разницы, вошёл ты или нет все удалиться

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

В любом случае:

А расскажу-ка я один прикол, который был на проектике. Как-то я заметил, что значение auto_increment в таблице юзеров сильно далеко уползло(за 400 миллионов). И юзеры создаются с большими дырками в айдишниках. Притом постоянно обсуждалась какая-то проблема с большой нагрузкой на эту самую таблицу(записей там было тоже немало). И я таки глянул как была реализована аутентификация+регистрация. Когда приходил успешный коллбек от фейсбуковского OAuth приложение... пыталось сделать insert в таблицу юзеров! try-catch ловил исключение, проверял текст на слово "Duplicate entry" и если это оно - то просто делал update users по нужному facebook_id - причем всех полей, которые пришли с фейсбука, не проверяя изменились они или нет! и все это, разумеется, на master базе данных...

Вот у меня например 20 e-mail я ж не все помню

И как думаешь сколько таких вот людей, которые 20 емейлов наплодили? Спрашивай телефон, если так. А лучше сделай oauth через основные соц сети и все

А расскажу-ка я один прикол, который был на проектике. Как-то я заметил, что значение auto_increment в таблице юзеров сильно далеко уползло(за 400 миллионов). И юзеры создаются с большими дырками в айдишниках. Притом постоянно обсуждалась какая-то проблема с большой нагрузкой на эту самую таблицу(записей там было тоже немало). И я таки глянул как была реализована аутентификация+регистрация. Когда приходил успешный коллбек от фейсбуковского OAuth приложение... пыталось сделать insert в таблицу юзеров! try-catch ловил исключение, проверял текст на слово "Duplicate entry" и если это оно - то просто делал update users по нужному facebook_id - причем всех полей, которые пришли с фейсбука, не проверяя изменились они или нет! и все это, разумеется, на master базе данных...

возникла проблема - ее решили.. в чем тут соль то?

возникла проблема - ее решили.. в чем тут соль то?

а кто сказал, что ее решили? :)

ну ты же посмотрел... значит исправил, т.е. решили

ну ты же посмотрел... значит исправил, т.е. решили

ну я думал, что забавная проблема. а оказалось что все так делают :(

жизнь - тлен

Ну как бы If you set a column to the value it currently has, MySQL notices this and does not update it.

я правда не понял, откуда дырки то

или там постгрес?

оно почемуто обновляло автоинкремент

мускул.. амазоновский... какойто. но не аврора

хм... странно, вроде не должен, но утверждать не возьмусь... но в целом... альтернуть до bigint и забыть о проблеме ?

хм... странно, вроде не должен, но утверждать не возьмусь... но в целом... альтернуть до bigint и забыть о проблеме ?

массовые апдейты когда не нужно :)

так мускуль ловит это, как написано... так что реально сделает апдейт только того, что нужно...

так мускуль ловит это, как написано... так что реально сделает апдейт только того, что нужно...

проще сделать select и проверить все и никаких insert&update не делать

во. не соврал я :)

я реально не проверял это. для меня это было очевидным следствием. я потом когда исправил - дырки исчезли

с точки зрения рейс кондишена, инсерт и апдейт лучше ?