API запись в базу данных?

Question

[MaximMRX]

Доброго времени суток, возник вопрос как можно реализовать API доступ который будет писать, обновлять базу? Интересует сам принцип работы. Нельзя же просто иметь ссылку на запись в базу..
Что-то вроде
/api/users/?action=getAllUsers // Получаем всех пользователей GET Запросом..
/api/users/?action=create
/api/users/?action=update&user_id=534
/api/users/?action=delite&user_id=957

Данные отправлять буду POST запросом AJAX// Но, тут вопрос стоит, об удалённом доступе? Ведь нельзя удалённо отправлять POST данные на сервер..
А так же как обеспечить безопасность, что не какой любопытный не смог воспользоваться API? Нужна проверка какая-то.. Про ключу что ли.. Что-то вроде..
/api/users/?action=getAllUsers&key=H35lgjs359gdsjl^648sfh523fa9sgwdlgs
Но, ведь смысла в этом нет передавать ключ в открытом виде..

Answer 1

[Руслан Полин]

Ведь нельзя удалённо отправлять POST данные на сервер

С чего вы это взяли?

/api/users/?action=getAllUsers&key=H35lgjs359gdsjl^648sfh523fa9sgwdlgs

Ключ должен быть зашифрован и передан POST/GET запросом вместе с остальными данными по протоколу https.

RESTful API PHP - вам нужно двигаться в этом направлении.

Comments

[MaximMRX]

Про ключ и шифрование и его передачу подробнее можно?
Вот мне например нужно создать пользователя AJAX запросом.
/api/users/?action=create

var data = form.serialize();
$.ajax({
	type: "POST",
	async: true,
	url:  'http://mySite/api/users/?action=create',
	cache: false,
	data:  data,
	success: function(data){
		// обрабатываем ответ
	}
});

[darksladen]

Максим Студитских: Так в чем ваша проблема? Берете просто и делаете запрос. Если ваш сервер использует протокол https, то данные будут автоматом передаваться в зашифрованном виде на уровне протокола.. Ключ же нужен для того, чтобы сделать идинтификацию пользователя, таким образом можно будет контролировать его доступ к апи. Вам же дали подробнейшую статью по этой теме, вам трудно прочитать ее? Там все отлично и понятно расписано!

[MaximMRX]

darksladen: Так в этом и проблема что нужен удалённый API доступ. И API без https

[Руслан Полин]

Максим Студитских: ajax не отправляет запросы на удаленные сервера и посему идентификация запроса упрощается, даже ключ доступа к API не нужен, только идентификация пользователя а именно токен.

Вопрос следующий. Для кого предназначено API? Если это OPEN API, то тут надо решать вопрос распределения доступа для разработчиков и идентификация оных. Если это RESTful API для своих проектов без возможности использования его другими разработчиками, то реализация уже другая.

Не использовать https - плохая практика в создании приложений тем более во времена активного продвижения протокола всеми кому не лень и тем более, когда сертификат можно получить бесплатно.

[MaximMRX]

Руслан: RESTful API, для своих проектов

[darksladen]

Руслан: ajax не отправляет запросы на удаленные сервера? Что простите??? Очень интересненько.. А по теме - www.michurin.net/computer-science/rsa.html - вот это читайте. Как выход - вы можете при каждом запросе к серверу генерировать открытый и закрытый ключи, отправлять данные на сервер, а вместе с ними открытый ключ, которым сервер и будет шифровать отдаваемые им данные. Сервер же в свою очередь будет давать вам открытый ключ, с помощью которого вы будете шифровать данные, летящие на сервер. Таким образом на каждой стороне должен быть свой закрытый ключ. Но клиенту кстати открытый ключ можно передать всего 1 раз, а вот серверу необходимо отдавать ему на каждом запросе, так как в куках закрытый ключ вы хранить не сможете, надо будет его генерировать постоянно. Ну вот как одно из решений..

А вообще ставьте на сервер https и не парьтесь, это будет лучшим решением без костылей!

[Руслан Полин]

darksladen: Политика безопасности браузера не позволит отправить стандартный ajax запрос, как кросс-доменный. Можно воспользоваться кросс-доменным ajax, но в таком случае на сервере, который его примет, должен быть прописан заголовок для кросс-доменных запросов, разрешающих их прием. Подробнее можно почитать тут XMLHttpRequest: кросс-доменные запросы

Answer 2

[Григорий Васильков]

На самом деле задача глубокая и очень сильно субьективная - типа как хочешь так и делай, вопрос безопасности безусловно всегда будет болеть.

Вот мои зарисовки:
https://vk.com/away.php?to=https%3A%2F%2Fdocs.goog...

В гугле допустим очень толсто сделано - есть сервис доступа у каждого большого приложения. Там создаются юзеры нескольких типов - это либо те, кто пользуется программой как клиент, либо админы, либо сервера (сервисные аккаунты).

Первые двое - это человеки, третьи - обычно компьютеры. Поскольку в отличие от компьютеров человеки имеют свойство все проебывать и забывать - им нужно постоянно получать разрешающий токен на сутки, что типа он это он. Компьютеру зашивается в файл секретный ключ и он отсылается при каждом запросе на твою систему, не требуя токена.

На почве этих идей чего только не сделали. Вконтакте например тебе нужно получить токен при каждом запросе с сервера или проверить - не вышел ли его срок. Зачем серверу токен - хер его знает. Ну может затем, что с компьютера могут спиздить жесткий диск, но опять же - что мешает с украденным файлом получить токен - ничего. Бесполезно.

У кого денег мало - в гет параметр засовывают пароль и просто его проверяют.
Средние бюджеты - делают регистрацию аккаунтов и выдают логины пароли, но это не годится для публичных сервисов, т.к. остаются долбоебы кто ходит в интернет с компа соседа и пиздит чужие пароли - для них и придумали токены и разрешение через СМС при малейшем намеке на смену местоположения.

На текущий момент самой четкой и безопасной системой считается белый список ip-адресов одновременно с ssh ключами и переброшенными портами от ssh. Ключи обеспечивают уникальность человека, ip - дополнительно указывают что скорее всего это кто-то конкретный пытается замутить какую-то дичь, а порты перебрасываются чтобы уменьшить число атак тупых ботов по 22. Но тут косяк, что ssh ключи они потому и ssh что позволяют получить доступ к консоли компа, а не допустим к пхп скрипту, так что можно только принцип подсмотреть.

Но допустим с этими ключами дикая несогласованность у создателей операционных систем, потому что они типа бы жутко подрывают "анонимность интернета". Поэтому обьяснить простому клиенту на сайте что такое пара ключей почти невозможно - это сьедает любой мозг, когда начинаешь путаться между приватным публичным, серверным приватным и серверным публичным и какой когда для чего нужен.

На деле там все просто - первый (приватный) принадлежит тебе и создается на твоем компе. С помощью него можно создать второй (т.е. публичный), который кому угодно отправить. Этот кто угодно добавляет его к себе в "белый список" и второе - добавляет его в папку к какому-то юзеру - чтобы связать логин с тобой - т.е. ты то можешь быть Гриха, а у него на компе ты gzhegow, и вот в папку gzhegow он кладет твой ключ, а потом еще в программку вносит что типа такому то ключу можно входить. После этого тот, у кого есть приватный может ходить туда, где его публичный в белом списке. В общем то все. Так делают связь например сервер-сервер - создали два приватных, на их базе два публичных, обменялись публичными - все работает - можно с одного сервера удаленно давать команду другому и им не нужна дибильная кнопка "разрешить подключение", которую должен нажать человек - серваки то небось один в Германии, другой в Камбодже.