Речь в топике идет о функции вычисления столения. К сожалению, функции пока не знают что такое «до н.э.» и не умеют работать с римскими цифрами. Вобщем-то об этом и топик по сути.
Я удивлен, что в Москве имеет место данная проблемма. У нас в Казани в любом более-менее уважающем себя магазине можно расплатиться карточкой… Может кризис?
… А потом посмотрел на ник автора статьи и понял — точно, crizis… Теперь и на хабре!
Ага. А вот теперь что будет, если пользователь захочет себе логин «new»? Будете на уровне скриптов ставить проверки логинов, которые нельзя создавать?
> Как раз /user/ и будет ресурсом. И вообще, в REST не задано жестко, что нельзя использовать множественное число.
Да, ресурсом типа индекс. Т.е. списоком.
Я говорил не про множественное число, а про сам порядок. Т.е. индекс не разделен от ресурса в плане структуры URL.
Нормально делается так:
/user/ — это твоя собственная страница, т.е. твой собственный профайл с возможностью изменения (или редирект на него). /user/{username} — профайл пользователя, в том числе и твой если логин соответствующий. Или же, /user/ — 404 страница, что очень даже логично.
/users/ — это именно список, причем тут есть творчество для фильтров: /users/all/, /users/friends/, /users/active/ и др.
Это я все к тому, что индекс и просмотр — это разные сущности, и мешать их нельзя (если не REST конечно). Вот почему: если у вас url /user/, то делее может быть только логин, и следовательно пространоство для фильтров с случае списка идет через гет-параметры, что не всегда хорошо.
Тоже касается остальных.
Да, если речь идет о REST — Там жестко — /user/ — индекс, /user/{login} — ресурс.
Кстати, можно было и проще сделать.
Сначала проапдейтить базу и существующий уже md5 закодировать еще раз md5, прибавив к нему salt.
При проверки соответственно такая же процедура — md5(md5($password).$salt). И понадежнее было бы, и тормошить никого не надо. А проблемму простых паролей эта мера все равно не решит.
А не все ли равно? Даже (в чем я сильно сомневаюсь) если и угнали базу (что с очень малой вероятностью может и возможно), то как бы вы поступили на месте «заклятой» администрации, а?
Когда занимаешься большими проектами, то понимаешь что такие меры часто бывают необходимы сами по себе.
… А потом посмотрел на ник автора статьи и понял — точно, crizis… Теперь и на хабре!
> Как раз /user/ и будет ресурсом. И вообще, в REST не задано жестко, что нельзя использовать множественное число.
Да, ресурсом типа индекс. Т.е. списоком.
Я говорил не про множественное число, а про сам порядок. Т.е. индекс не разделен от ресурса в плане структуры URL.
> повторить успех Джорджа, и ни одна не приобрела популярность.»
А знаете почему? Потому что наши люди деньги особо не рассматривают. :-)) Делать больше нечего что ли? :-)
/user/ — это твоя собственная страница, т.е. твой собственный профайл с возможностью изменения (или редирект на него). /user/{username} — профайл пользователя, в том числе и твой если логин соответствующий. Или же, /user/ — 404 страница, что очень даже логично.
/users/ — это именно список, причем тут есть творчество для фильтров: /users/all/, /users/friends/, /users/active/ и др.
Это я все к тому, что индекс и просмотр — это разные сущности, и мешать их нельзя (если не REST конечно). Вот почему: если у вас url /user/, то делее может быть только логин, и следовательно пространоство для фильтров с случае списка идет через гет-параметры, что не всегда хорошо.
Тоже касается остальных.
Да, если речь идет о REST — Там жестко — /user/ — индекс, /user/{login} — ресурс.
Сначала проапдейтить базу и существующий уже md5 закодировать еще раз md5, прибавив к нему salt.
При проверки соответственно такая же процедура — md5(md5($password).$salt). И понадежнее было бы, и тормошить никого не надо. А проблемму простых паролей эта мера все равно не решит.
А обычный пользователь как правило вообще презентаций не смотрит.
Когда занимаешься большими проектами, то понимаешь что такие меры часто бывают необходимы сами по себе.