Задать вопрос
  • Правильно ли я понял, как работает токен?

    xmoonlight
    @xmoonlight
    https://sitecoder.blogspot.com
    Я мимо проходил и, вроде, все верно, кроме:
    С мобильного приложения я отправляю логин и пароль на сервер api.
    Никогда! Слышишь, Карл?! НИКОГДА НЕ ПЕРЕСЫЛАЙ данные авторизации на сервер БЕЗ ПРЕДВАРИТЕЛЬНОГО ХЕШИРОВАНИЯ на стороне клиента серверным ключом.

    1. Данные на клиенте: hash(USER1:PASSWORD:SKEY:RANDOM),
    2. Пересылаю на сервер: ab1e37ab50c61d8c80fb5cb4b1e3122f:RANDOM
    3. Ищу на сервере совпадение:
    ab1e37ab50c61d8c80fb5cb4b1e3122f===hash(USER:PASSWORD:SKEY:RANDOM) и получаю учётку пользователя, если все верно.

    А так, да! Спасибо, Сергей Протько - все довольно четко и верно написано!
    Ответ написан
    42 комментария
  • Правильно ли я понял, как работает токен?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Да. Все верно.

    Единственное что добавлю, пересылать токен лучше в заголовках. Причем желательно, поскольку механизм аутентификации нестандартный, в заголовке X-Authorization. Если вы решите хранить токен в куках и передавать его, это желательно должны быть http-only куки (хотя в случае JWT не обязательно) и на сервере должна быть защита от CSRF атак.

    Так же поскольку у нас по сети гуляют по сути креденшелы, важно использовать SSL. Благо сегодня есть lets-encrypt что бы бесплатно получить сертификаты.

    И последнее, что бы обезопасить себя еще, используйте refresh-токены. То есть наш уникальный токен который гуляет в каждом запросе будет иметь ограничение по времени жизни (скажем 5 минут) и для его обновления мы будем использовать refresh-токен. При получении refresh токена клиенту уходит новая пара токен + refresh-токен.

    Таким образом у злоумышленника который перехватил токен пользователя будет окно всего в 5 минут что бы что-то сделать.
    Ответ написан
    13 комментариев
  • Какова роль интерфейсов в ООП?

    Приведу пример на коленке. Хотим, например, написать абстрактную файловую систему. Для начала, определим интерфейс, для ФС:

    interface FileSystemInterface {
      public function write($file, $data);
      public function read($file);
    }


    Затем, хочу реализацию интерфейса ФС для работы с файликами:

    class OSFileSystem implements FileSystemInterface {
      public function write($file, $data) {
         // открываем файлик, пишем данные
      }
    
      public function read($file) {
        // открываем файлик, возвращаем данные
      }
    }


    Вдруг, кому-то захотелось файловую систему в облаке. Окей, не проблема, реализуем это:
    class CloudFileSystem implements FileSystemInterface {
      public function write($file, $data) {
         // открываем соединение с облаком, пишем данные
      }
    
      public function read($file) {
        // открываем соединение с облаком, возвращаем данные
      }
    }

    Пусть у нас есть кой-то код, работающий с файловой системой, назовем его "Хранилище файлов". Пусть он выглядит примерно так:

    class FileStorage {
      protected $Fs;
      
      public function __construct(FileSystemInterface $Fs) {
        $this->Fs = $Fs;
      }  
    
      public function saveFile() {
        $this->Fs->write('file.txt', 'file data');
      }
    
      public function getFile() {
        return $this->Fs->read('file.txt', 'file data');
      }
    }


    Отлично! Теперь мы можем хранилищу файлов отдать любой объект с реализованным интерфейсом FileSystemInterface. Пример:

    // Хранилище файлов работает с файловой системой ОС:
    $FS = new OSFileSystem();
    $FileStorage = new FileStorage($Fs);
    $FileStorage->getFile();
    
    // Хранилище файлов работает с файловой системой в облаке:
    $FS = new CloudFileSystem();
    $FileStorage = new FileStorage($Fs);
    $FileStorage->getFile();


    Использование интерфейса, в данном случае. позволяет нам писать только реализацию работы файловой системы, а бизнес-логика, работающая с файловой системой никак не меняется, она знает, что в любом случае файловая система реализует интерфейс FileSystemInterface и может без опаски использовать методы этого интерфейса.
    Ответ написан
    14 комментариев
  • Верстка в Linux?

    zorro76
    @zorro76
    Я перешел с винды на Ubuntu 3 месяца назад. Все ок и все работает должным образом. Начиная от командной строки и заканчивая редактором. А то что нет полноценного Photoshop это миф. Посмотри тут https://www.youtube.com/watch?v=wjmQJckOATM И собственно зачем Photoshop верстальщику, понятно что для посмотреть макет и нарезать, все. Правда все это можно сделать и на gimp, но тут дело вкуса. Лично я за продукт Adobe assets.adobe Все остальное настраивается и работает на Linux в разы проще и быстрее. node, npm, bower, gulp, grunt, git ... да собственно все, что нужно фронт-энд разработчику. Тот же looftblog выложил видео с настройкой среды разработчика на Linux https://www.youtube.com/watch?v=DfSm7SVq4LA

    UPD: и да сейчас вообще Avocode рулит
    Ответ написан
    4 комментария
  • За кем следить на GitHub?

    JSinga
    @JSinga
    Итак попытаемся разобраться и сделать это логично:
    Мы любим фронтенд значит нам нужно что то на языке JavaScript - ищем на гитхабе проекты с большим кол-вом звездочек и все еще "живые":
    github.com

    Смотрим неколько проектов и смотрим там на контрибьюторов которые внесли много коммитов результат:
    pazguille
    getify
    spicyj
    hhaidar
    nolimits4web

    То же самое для html:
    PaulKinlan
    hubgit
    Ms2ger
    LeaVerou - обратите внимание это девочка и еще и из MIT
    davelab6
    enaqx

    Попутно смотрим в какие группы эти ребята входят и отмечаем инетересные
    reactjs
    html5rocks
    GoogleChrome

    Ну алгоритм вам надеюсь понятен, дальше можно просматривать бесконечно!
    Ответ написан
    1 комментарий