Да, хороший вариант, спасибо. Я, скорее всего, у себя оставлю, как есть. Но все желающие приглашаются на github для развития проекта (если вдруг есть такое желание) =)
Как правило, для решения 95% задач программирования хватает умения построить выражения вида «if A or (not A and B)», а еще 4% также не требуют знания импликации.
Ммм…Я с первой вообще-то дал :)
В любом случае, не считаю такую задачу профильной для Хабра. Это хоть и IT-ресурс, но большинство задач, решаемых посетителями Хабра это веб-программирование, верстка и дизайн. Каким боком к этим задачам относится знание импликации — не знаю.
Без фреймворков вообще? Это примерно то же самое, что писать веб-приложения на C++ — а кто должен заниматься взаимодействием с веб-сервером (Rack — это тоже фреймворк) и выполнять рутинные задачи (отсылка HTTP-заголовков и всё в таком духе). Можно, конечно, писать CGI-приложения в стиле классических perl-скриптов середины 90-х, но неужели это действительно практично? А Camping уже погиб, как я недавно узнал — так что о нем писать тоже бессмысленно.
Вариантом, действительно свободным от коллизий, будет именно дайджест по всему файлу, но полагаю, что это довольно неэффективно с точки зрения ресурсов сервера.
и вы окажетесь полным дураком, откуда продавей магазина узнал вашь номер? он телепат чтоли?
С карточкой, которой вы расплачивались, возникли проблемы, магазин обратился в банк, банк сообщил номер. А вообще могут и банком представиться.
Да и в сервисе можно зарегаться хоть Васей Самизнаетекаким.
А можно еще и фейковые транзакции указывать для верности :) В том-то и дело, что проще пользоваться защищенным сервисом, которому доверяешь — тогда не надо придумывать левые имена, исключать из сервиса транзакции вида «Купил травки у Васи», да и вообще беспокоиться.
Кевин Митник очень хорошо писал в книге «Искусство обмана»: человек, обладающий информацией, которую вы считаете приватной, может убедить вас во многом.
Представьте, что я получил доступ к вашим записям в подобном финансовом сервисе, звоню вам и представляюсь сотрудником магазина, сообщаю вам все ваши покупки из последнего чека и прошу вас сделать что-то, что нужно мне. Скорее всего, вы мне поверите и сделаете, что я скажу — кто еще может знать, что вы купили в магазине, кроме его сотрудников.
Не знаком с django orm и sqlalchemy вообще, но класс можно мапить только на таблицу (возможно и на представление, но сталкиваться с таким не приходилось).
Почему же SESSID? Это как раз некое подобие SSL выходит — криптография с открытым ключом. Клиент шифрует свой логин+IP закрытым ключом (=паролем) и отсылает серверу — сервер проводит аналогичную операцию и сравнивает результат. При этом кража зашифрованного значения подойдет только при попытке зайти под тем же юзером с того же IP.
А зачем авторизация без сессий, если мы храним логин-пароль в cookies? Мы просто при всех запросах отсылаем такой cookie и нас либо пускает, либо не пускает (например, выдает 403).
Боюсь, что не подскажу, так не знаю их таких. Для написания своих статей я использовал — оффсайт Синатры, пару тематических постов в блогах (искал под конкретные задачи в гугле запросами вида «sinatra authorization» и «sinatra configuration») и исходниками самого проекта. На русском не видел вообще ничего.
На самом деле, большая часть возможностей Синатры уже описана в двух статьях (в третьей доведу полноту до 90%) — дело в том, что Синатра это действительно небольшой фреймворк, который не так уж много умеет «из коробки».
Проще говоря идентифицирующее данные, например, логин/пароль (хеш пароля) должны быть в каждом запросе, предполагающем аутенфикацию/авторизацию?
Совершенно верно.
P.S. И, кстати, а собственно запрос аутенфикации в идеологии REST должен передаваться каким HTTP методом? По идее этот запрос только изменяет контекст, а не создает, не изменяет и уж, конечно, не удаляет ресурсы на сервере, и методом исключения приходим, что это должен быть GET запрос :-/
Вы же сами только что написали, что логин-пароль должны присутствовать в каждом запросе — это и есть чистый REST. В реальной жизни он неудобен, поэтому обычно всё-таки используют сессии и авторизацию 1 раз за сеанс. В этом случае, авторизация — это создание сессии — значит POST-запрос. А выход из системы — удаление сессии — DELETE запрос.
Честно говоря, не смотря на громкий заголовок, я не ставил своей целью рассказать про REST «в общем случае», я лишь пытался ответить на вопрос «какие плюшки дает применение PUT/DELETE», о чем честно заявил в самом начале статьи.
Не совсем так, но вопрос действительно интересный и сложный.
REST постулирует, что сервер должен отвечать за состояние ресурса, в то время как клиент — за состояние «приложения» (=контекст). Если cookies используются в качестве «ссылки» на состояние приложения, хранимое на сервере (например, содержат session_id), то это не RESTful подход (вернее, не совсем RESTful), если же Cookies содержат всю информацию, необходимую для определения контекста, то это вполне RESTful. Потому что запрос клиента должен полностью и однозначно определять контекст, а cookies — это часть запроса.
Вот это уже интереснее, но если надо разным знакомым и довольно случайно распределенным (во всяком случае, минимум половина из них не захочет ставить какие-либо клиенты)
В любом случае, не считаю такую задачу профильной для Хабра. Это хоть и IT-ресурс, но большинство задач, решаемых посетителями Хабра это веб-программирование, верстка и дизайн. Каким боком к этим задачам относится знание импликации — не знаю.
8×8 = 64 > 50 — правая часть ложь, но на самом деле это уже неважно.
Ответ: 7
С карточкой, которой вы расплачивались, возникли проблемы, магазин обратился в банк, банк сообщил номер. А вообще могут и банком представиться.
А можно еще и фейковые транзакции указывать для верности :) В том-то и дело, что проще пользоваться защищенным сервисом, которому доверяешь — тогда не надо придумывать левые имена, исключать из сервиса транзакции вида «Купил травки у Васи», да и вообще беспокоиться.
Представьте, что я получил доступ к вашим записям в подобном финансовом сервисе, звоню вам и представляюсь сотрудником магазина, сообщаю вам все ваши покупки из последнего чека и прошу вас сделать что-то, что нужно мне. Скорее всего, вы мне поверите и сделаете, что я скажу — кто еще может знать, что вы купили в магазине, кроме его сотрудников.
На самом деле, большая часть возможностей Синатры уже описана в двух статьях (в третьей доведу полноту до 90%) — дело в том, что Синатра это действительно небольшой фреймворк, который не так уж много умеет «из коробки».
Совершенно верно.
Вы же сами только что написали, что логин-пароль должны присутствовать в каждом запросе — это и есть чистый REST. В реальной жизни он неудобен, поэтому обычно всё-таки используют сессии и авторизацию 1 раз за сеанс. В этом случае, авторизация — это создание сессии — значит POST-запрос. А выход из системы — удаление сессии — DELETE запрос.
Честно говоря, не смотря на громкий заголовок, я не ставил своей целью рассказать про REST «в общем случае», я лишь пытался ответить на вопрос «какие плюшки дает применение PUT/DELETE», о чем честно заявил в самом начале статьи.
REST постулирует, что сервер должен отвечать за состояние ресурса, в то время как клиент — за состояние «приложения» (=контекст). Если cookies используются в качестве «ссылки» на состояние приложения, хранимое на сервере (например, содержат session_id), то это не RESTful подход (вернее, не совсем RESTful), если же Cookies содержат всю информацию, необходимую для определения контекста, то это вполне RESTful. Потому что запрос клиента должен полностью и однозначно определять контекст, а cookies — это часть запроса.