Можно ли передавать security token как URL параметр?

Можно ли передавать security token как URL параметр?

Есть задача создать временную интеграцию между новой (Salesforce-based) и легаси системами,

на стороне новой системы можно сделать Web-service, но выглядит сложно для временного решения.

проще сделать интеграцию на основе обмена email and email-listeners.

также как вариант думаю о restfull vf-page, вариант который давно еще предлагал Gres. С вариантом, когда vf-page использует авторизовавшимся пользователем все понятно, в вот если restfull vf-page экспонировать как сайт-пейд, то как обеспечить минимальную секьюрность? Использовать security token, но как его передавать в контроллер? только как URL параметр? И возникает вопрос: а безопасно ли передавать "многоразовый" security token как URL параметр?

сторонний вопрос, почему написать email-listeners проще чем Web-service ?

сохрани свой токен как label или как hierarchy custom setting , и к тому и к тому есть доступ напрямую из вижуалфорса

https://developer.salesforce.com/docs/atlas.en-us.pages.meta/pages/pages_variables_global_setup.htm

Андрей
сохрани свой токен как label или как hierarchy custom setting , и к тому и к тому есть доступ напрямую из вижуалфорса

Если я правильно понял, Den Brown хочет просто выставить в интернет VF страницу, которая будет использоваться как интеграция. Т.е. get'нул эту VF страницу - у тебя создались записи в СФ.

Den Brown, главный вопрос - почему нельзя использовать другие, более правильные методы интеграции? Webservice, REST API етц? Если вопрос только в сложности, то, как по мне, создать ВФ страницу и заэкспоузить ее наружу выглядит в разы сложнее, чем написать веб сервис.
Если по каким-то причинам все-таки нужна VF page - то я бы использовал хотя бы public key передаваемый через URL параметр. Хотя бы защита от того, что кто-то левый не зайдет на сайт и не завалит орг кривыми данными.

EvAzi
Если я правильно понял, Den Brown хочет просто выставить в интернет VF страницу, которая будет использоваться как интеграция. Т.е. get'нул эту VF страницу - у тебя создались записи в СФ.

правильно, и в боди страница вернула какую то инфу

EvAzi
почему нельзя использовать другие, более правильные методы интеграции? Webservice, REST API етц?

можно, я уже начинаю склонятся в эту сторону. Но поднять, например, кастомный SOAP сервис - это одна сторона вопроса, кроме этого еще нужно помочь другим людям (на стороне легаси приложения) написать для него клиент, а в нем обязательно должна быть авторизация... не знаю стоит ли со всем этим связываться для временной интеграции... но вероятно придется

Андрей
почему написать email-listeners проще чем Web-service ?

я помню старо-давние времена, когда СФ рекомендовал во всех случаях где возможно использовать email-listeners-based интеграцию, как самый простой способ (плюс Outbound messages). Сейчас они уже так не говорят, но вариант остался

в реальности требования довольно странные и вероятно основаны на непонимании заказчика как (сложно) это все работает. Есть две паралельные ситуации:
(1) легаси приложение которое имеет WS client to third-party платежному WS service. И third-party платежный WS service меняет то ли формат, то ли протокол своего WS service, в результате чего существующая интеграция с легаси приложением через полгода перестанет работать.
(2) паралельно мы начинаем работу по миграции легаси приложение на СФ платформу, и в новом приложении мы сделаем новый WS client to third-party WS service, который уже будет в новом форме и все ок.

Но не долго музыка играла! Внезапно клиент хочет, чтоб мы помогли им поддержать интеграцию между легаси приложением и third-party WS service на какое-то время. При этом они по неведомым причинам не хотят просто запилить новый WS client на легаси приложении чтоб он продолжил работу с third-party WS service, а хотят использовать СФ орг как посредник в процессе, т.е. нужна интеграция между легаси и СФ оргом, возможно в виде веб-сервиса:
- легаси имеет WS client к нашему новому кастомному WS service который в свою очередь вызывает WS client to third-party WS service. Звучит сложно, и сделать это еще сложнее: принять WS client call от легаси, сделать call to third-party WS service, получить от него response, и переправить его как response в легаси. Получится ли вообще это сделать синхронно? а если делать несинронно, то email-listrner-based integration выглядит проще для меня

чет не совсем понятно. SOAP или REST используется. Ладно еще с SOAP понятно что сложновато, потому что не каждый день используется и надо в доках покопаться, но REST Web Service открыть на стороне SF это ж 10 минут работы копипаста 10 строк. "email-listrner-based integration" - что? первый раз вообще про такую слышу, и когда она была рекомендованной? Понимаю сделать Email Listener когда надо работать с Emails (принимать их) но делать на Emails интеграцию? Не кажется что предназначение Emails немного в другом? И вообще кто вам гарантирует что ваши Emails 100% дойдут куда надо? Для этого и существует REST. И ничего в нем сложного нет. Придумываем красивый endpoint, создаем Apex Class где прописываем REST Web Service и ждем когда придут запросы.

Теоретически пересылать запросы через SF можно как временное решение, но нужно быть готовым к различного рода проблемам, так как обычная прямая связь растягивается уже по цепочке на несколько систем и ХЗ где может упасть. Отлаживать такие системы уже будет сложно. (Надо кстати еще проверить можно ли послать HTTP Callout из WebService). И вот тут самое интересное - с Email Listener такое уже хрен провернешь.

На счет RESTfull VF + SecurityToken. Тут раельно гемору по сравнению с обычным REST Web Service получится в разы больше. ПОтому что, во-первых надо страницу прокинуть в открытый доступ, а это надо гемороиться с настроками сайта, открывать страницу, права Site Guest User надо учитывать, пилить свою систему авторизации, на том же token.

И наконец, ответ на самый основной вопрос темы - "Можно ли передавать security token как URL параметр?". А какая разница как ты передаешь свой security token - в headers, в POST body, в GET параметре. Один фиг где бы он не лежал он находится в тебе запроса. Другой дело чтобы ты не постил такие ссылки (с security token) куда-то на Facebook или в Одноклассники Тогда реально будет косяк

Dmitry Shnyrev
нужно быть готовым к различного рода проблемам, так как обычная прямая связь растягивается уже по цепочке на несколько систем и ХЗ где может упасть. Отлаживать такие системы уже будет сложно.

вот это пытаюсь им объяснить

а так, согласен с вами, проще запилить интеграцию на основе REST Web Service и пусть интегрируются

правда остается вопрос

Dmitry Shnyrev
можно ли послать HTTP Callout из WebService

Den Brown
правда остается вопрос

Dmitry Shnyrev
можно ли послать HTTP Callout из WebService

Ну это же легко проверить

Dmitry Shnyrev
Ну это же легко проверить

сначала погуглю :)

Den Brown
я помню старо-давние времена, когда СФ рекомендовал во всех случаях где возможно использовать email-listeners-based интеграцию, как самый простой способ (плюс Outbound messages).

скорее всего я ошибаюсь, спутав с вот этой фразой:

Use outbound messaging to handle integration solutions when possible. Use callouts to third-party web services only when necessary.

Dmitry Shnyrev
Ну это же легко проверить

проверил, вот этот код работает:

@RestResource(urlMapping='/Calculator/*')

global with sharing class REST_Calculator_WS {

@HttpPost
global static Double doAdd(String firstNumber, String secondNumber) {

Double x = Double.valueOf(firstNumber);
Double y = Double.valueOf(secondNumber);

// callout to SOAP WS
calculatorServices.CalculatorImplPort calculator = new calculatorServices.CalculatorImplPort();

Double result = calculator.doAdd(x,y);
System.debug(result);

return result;
}
}

стукнул ПОСТ в Workbench, приходит результат

Ну вот и отлично! Клиент спасен от страшных костылей

Interesting information? Help us, post link to social media..