Основанная на сервисе аутентификация Используя маркеры
Если ваши данные являются массивом, ваш исходный код будет работать, если вы избавитесь от скобок вокруг данных:
var data = [32710,20280,18002];
console.log(data);
console.log(d3.min(data));
console.log(d3.max(data));
Если вам нужно идентифицировать значения массива с помощью ключей «01», «02», «03», создайте массив объектов и оперируйте значениями, чтобы получить min / max:
//data as key/value pairs
var data = [
{key: "01", value: 32710},
{key: "02", value: 20280},
{key: "03", value: 18002}
];
console.log(data);
console.log(d3.min(data, function(d) { return d.value; }));
console.log(d3.max(data, function(d) { return d.value; }));
// AND IF YOU WANT THE min/max of the KEYS:
console.log(d3.min(data, function(d) { return d.key; }));
console.log(d3.max(data, function(d) { return d.key; }));
5 ответов
Я предполагаю, что "токен" в данном случае просто должна быть либо зашифрованной строкой что клиент может расшифровать или некоторые случайная строка, которая сохраняется где-нибудь (например, в базе данных), что затем клиент может проверить против, но Я не совсем уверен, что это за клиент тогда предполагается использовать токен или зачем вообще нужен токен - не может также простой идентификатор пользователя Достаточно?
Нет - жетон - это «проездной». Прямо как жетон метро. Клиент предоставляет его привратнику при запросе услуги. В этом случае провайдер выполняет свою собственную аутентификацию, поэтому клиент возвращает токен провайдеру. В некоторых случаях провайдер может делегировать аутентификацию - например, в модель STS , и в этом случае провайдер может передать токен третьей стороне для аутентификации и даже авторизации.
С точки зрения обслуживания, этот токен должен:
- иметь «срок годности». В противном случае токен можно было бы многократно использовать повторно. Таким образом, на стороне сервера вы можете сохранить токен в хранилище на основе сеанса, где вы получите тайм-аут бесплатно. Или вы можете построить простую хеш-таблицу с истечением срока действия.
- быть привязанным исключительно к держателю. Во многих случаях провайдер использует здесь приблизительное значение и утверждает, что токен может использоваться только с исходного запрашивающего IP-адреса.
Итак, на шаге 3 провайдер должен проверить имя пользователя и пароль. Если это подтвердится, создайте токен (хеш), который ссылается на запись в Словаре или Hashtable. Объекты в Hashtable - это структуры, содержащие имя пользователя, IP-адрес, возможно, исходное время выдачи, возможно, роли, связанные с именем пользователя, и все, что вы хотите сохранить. Поставщик услуг отправляет обратно этот токен - хэш, а не структуру - клиенту, обычно в виде Set-Cookie. Когда клиент отправляет обратно токен (как файл cookie) при последующих запросах, провайдер проверяет словарь, чтобы увидеть, доступен ли токен, не истекло ли время ожидания, соответствует ли запрашивающий IP-адрес, Я бы посоветовал людям изучить OAuth 2.0 Framework и токены Bearer.
В основном они делают именно то, что здесь описано.
Если вам нужен хороший пример реализации, вы можете посмотреть Usergrid Apigee. Это работает следующим образом:
Пользователь аутентифицирует
POST https://api.usergrid.com/token -d '{"имя пользователя": "Джо", "пароль": "Sec4et!", "Grant_type": "password"} 'Пользователь получает токен доступа в ответ
Пользователь выполняет последующие вызовы с заголовком
Авторизация: носитель XXXXXXXXXX, где XXXXX заменяется токеном носителя. Этот токен имеет время жизни, установленное сервером пользовательской сети.
A typical token is a random hash that's stored on the server side. The client passes it back with its requests. What this gets you is that you don't have to pass around the password all the time, which is obviously all to the good, and the token can be invalidated any time you like without having to change the password.
Я нашел эту документацию для Amazon S3 полезной, когда искал ту же проблему.
Общий принцип состоит в том, что вы не хотите передавать свои имя пользователя и пароль для каждого последующего вызова службы, поскольку это будет небезопасно.
Вы упомянули о простой передаче имени пользователя обратно в службу, однако, опять же, это будет не очень безопасно.
Вы можете подумать об использовании состояния сеанса для хранения факта аутентификации пользователя, однако это противоречит одному из общих принципов REST, согласно которому все должно быть без состояния.
Веб-сервис с сеансами ... хммм, так быть не должно. Веб-сервисы не предназначены для сохранения состояния.
Я поискал в Интернете, и в большинстве примеров и статей говорится о SSL / TLS + имени пользователя и пароле. Было бы неплохо заменить имя пользователя / пароль инфраструктурой «API-ключ», но я понятия не имею, как «спроектировать» такую вещь ...