В этот новый год путешествовал по штатам, съездил заодно в долину посмотреть. Сходил в Гуглоплекс (там можно спокойно по территории гулять), в Facebook, поездил по городишкам. Навскидку — 50% индусы, 20% китайцы, 30% — сборная мира. Может кто-то из живущих там меня поправит.
«финал головного мозга» ))
я привык к final, с ним все ясно и понятно акже есть еще ощущение, что я смогу запроксировать произвольный урл сроком годности до 2410 года
не должно, timeStampExpires генерится на сервере
хороший вопрос, по логике если если переменная параметра не меняется в методе то можно было бы и поставить.
Вот совершенно не понимаю использования final для переменных.
с другой стороны удобно. Если смотришь чужой код ты точно знаешь что меняя эту переменную (которая была final) ты можешь где-нибудь накосячить и кто-то в коде ниже надеется что она final
да, неплохая схема. Только не очень понял зачем в родителе держать dom клон того что в iframe (если я правильно понял). Еще вариант целиком редактор страницы заембедить в редактируемую страницу (это к комменту выше)
у нас там все по простому, без base. На самом деле сейчас использовать относительные урлы не модно, и часто приходится смотреть в код всяких сайтов — относительных почти нигде уже нет
вопрос в том что кто-то должен принять ваше сообщение на строннем сайте.
В нашем случае вмя история с прокси нужна для того чтобы как раз внедрить в чужой html наш JS который будет слать postMessage
ну клиентское шифрование — чего такого ) Наверняка Mega не хранит ключик в хэш урле. Тут фишка именно в том чтобы без регисрации и паролей придумать самый секьюрный способ передачи данных через веб сервис
мне кажется не суть, ну возьмет он из access логов вторую половину ключа а первую из кода, раз уж добрался. Разделение этого ключа на 2 части ничего не решает.
Если уж параноить тут можно так сделать еще интереснее:
анкор (хэш) урлы не уходят из браузера. Браузер при переходе вот по такой урле http://habrahabr.ru/#search_form отшлет на сервер get запрос только habrahabr.ru/
Это можно заюзать таким образом. Оставляем всю вашу схему с серверным шифрованием но перед этим еще и шифруем на клиенте (в браузере перед отправкой на сервер). Ключик клиентского шифрования пока храним в браузере. После того как сервер вернул сгенеренную урлу, дописываем ключ клиентского шифрования через хэш: secureshare.pw/s/617cde716b6f4bfb34...#client_side_secret_password
теперь все стало еще сложнее потому как client_side_secret_password никуда не уйдет из браузера (в логи апача, провайдера и тп)
тогда получается вообще незачем делить случайное число на две части. Пришли данные от поьзователя, сгенерил случаное число, зашифровал данные, сложил их в базу. Клиенту отдал сгенерированное случайное число и id записи.
В чем прикол хранить половину у себя? от жесткого перебора это все равно не спасет
Молодцы (без сарказма).
я привык к final, с ним все ясно и понятно
акже есть еще ощущение, что я смогу запроксировать произвольный урл сроком годности до 2410 годане должно, timeStampExpires генерится на сервере
с другой стороны удобно. Если смотришь чужой код ты точно знаешь что меняя эту переменную (которая была final) ты можешь где-нибудь накосячить и кто-то в коде ниже надеется что она final
)) Мне кажется редирект спасет
Я не уловил идеи, что этот конфиг делает?
вопрос в том что кто-то должен принять ваше сообщение на строннем сайте.
В нашем случае вмя история с прокси нужна для того чтобы как раз внедрить в чужой html наш JS который будет слать postMessage
Если уж параноить тут можно так сделать еще интереснее:
анкор (хэш) урлы не уходят из браузера. Браузер при переходе вот по такой урле http://habrahabr.ru/#search_form отшлет на сервер get запрос только habrahabr.ru/
Это можно заюзать таким образом. Оставляем всю вашу схему с серверным шифрованием но перед этим еще и шифруем на клиенте (в браузере перед отправкой на сервер). Ключик клиентского шифрования пока храним в браузере. После того как сервер вернул сгенеренную урлу, дописываем ключ клиентского шифрования через хэш:
secureshare.pw/s/617cde716b6f4bfb34...#client_side_secret_password
теперь все стало еще сложнее потому как client_side_secret_password никуда не уйдет из браузера (в логи апача, провайдера и тп)
В чем прикол хранить половину у себя? от жесткого перебора это все равно не спасет