испытаем лаунчер?

Практические советы по работе с FileMaker, типичные задачи и их решения. У вас вопрос? Пишите сюда.
Ответить
andrey volkov
Сообщения: 338
Зарегистрирован: 11 сен 2017, 13:42
Откуда: Санкт-Петербург

испытаем лаунчер?

Сообщение andrey volkov » 30 дек 2018, 14:26

В последних версиях файлмейкера сделали возможность запускать полноценные web-direct приложения в браузерах смартфонов. Это усилило позиции файлмейкера, ибо раньше иметь мобильную связь с удаленными базами данных и "держать руку на пульсе" могли лишь обладатели iOS устройств.
Веб-директ приложение - в принципе неплохая альтернатива айфонам с FileMaker Go; опытный разработчик способен реализовать на этой платформе достаточно емкий и надежный функционал. Неудобство доставляет лишь то, что, запуская приложение в браузере смартфона, пользователь вынужден каждый раз повторять процедуру авторизации, и это делает мобильное приложение ощутимо неудобным.



На одной из конференций по файлмейкеру был поднят вопрос: можно ли каким-либо способом сделать так, чтобы используемые для входа логин и пароль пользователя сохранились. И чтобы в следующий раз запроса авторизации не было (либо по умолчанию подставлялись бы сохраненные логин и пароль). В качестве решение было предложено использовать технологию куки (Cookie).
Пару слов об этой технологии. Из соображений безопасности в любом браузере реализован принцип, запрещающий веб-приложениям взаимодействовать с компьютером пользователя. Веб-приложение не может ни считывать данные с компьютера пользователя, ни осуществлять запись на них. Вообще сценарий веб-приложения всегда исполняется на веб-сервере, браузер лишь получает от сервера итоговые данные (в виде html файла), которые должен корректно отобразить на экране.

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

Эта технология может использоваться и для автоматической авторизации пользователя мобильного телефона. Процедура в целом будет исполняться по следующей схеме.
1) При запуске веб-директ приложение файлмейкер неким образом запрашивает куки у браузера.
2) Если браузер находит куки, то он делает эту информацию доступной для файлмейкера.
3) Файлмейкер извлекает из данных пару "логин/пароль" и пытается авторизоваться.
4) Если авторизация проходит успешно, то веб-директ приложение продолжает работать в авторизованном режиме.
5) Если куки не найдены, либо авторизация не проходит, файлмейкер приглашает пользователя ввести логин и пароль. Пользователь вводит логин и пароль, файлмейкер проверяет их валидность.
6) Если пара "логин/пароль" валидна, то файлмейкер совершает процедуру сохранения этой пары в куках браузера и далее продолжает работу в авторизованном режиме.

Мы знаем уже, что файлмейкер сам по себе не может управлять куками. Но у него есть элемент управления web-viewer, при помощи которого можно уже задействовать веб-технологии. Собственно, веб-технологиями могут быть PHP сценарии, которые файлмейкер заставит исполниться в веб-вьюере. Либо это могут быть, например, некие JAVA сценарии.

Я предлагаю решение, в котором используются PHP сценарии.
Всего требуется три сценария. Для простоты я реализую каждый сценарий в отдельном php файле.
Эти php файлы должны быть размещены на сервере FileMaker Server, в директории
~~ FileMaker Server\Web Publishing\web-server-support\test\fmi-test\
В специальной папке.
Допустим, папка будет называться php, тогда путь к ней будет
~~ FileMaker Server\Web Publishing\web-server-support\test\fmi-test\php\
В эту папку мы и скопируем файлики со сценариями.

Отметим, что для этой папки потребуется настроить специальные разрешения, которых по умолчанию пользователю не предоставлены: это разрешения на чтение и запись.

Итак, сценарии.
Первый сценарий (setc.php) будет заставлять браузер записывать куки
Файлмейкер заставляет web-viewer перейти на страничку с адресом типа
ht tp:/ /199.99.111.124:99/fmi-test/php/setc.php?username=validaccountname&userpwd=validpassword
Логин и пароль мы передаем в параметрах урла, далее свою работу выполнит файлик setc.php

Второй сценарий (recc.php) заставит браузер прочитать куки на локальном устройстве и записать результат в текстовый файл с именем [random_uuid].txt
Этот файлик появится после исполнения сценария рядом с файлом сценария, в папке php (для этого и нужны специальные права на запись).
Запускается сценарий с помощью web-viewer'а, который мы заставляем перейти по ссылке вида
http:/ /199.99.111.124:99/fmi-test/php/recc.php?uuid=random_uuid

Зачем нам нужно записывать результат в файл? Да очень просто. Даже если бы мы вывели результат в окне веб-вьюера, файлмейкер не смог бы прочитать его (в режиме веб-директ у файлмейкера нет доступа к содержимому страницы веб-вьюера). Поэтому приходится записать результат в отдельный файл. Ну, а уж прочитать файл можно без труда. Для этого выполняем команду Insert From URL, в качестве урла указываем:
http:/ /127.0.0.1/fmi-test/php/getc.php?uuid=random_uuid
(в качестве параметра в ссылке передается тот же uuid, что ранее был использован для вызова второго сценария)

Что сделает этот третий (getc.php) сценарий? Он прочитает и вернет файлмейкеру содержимое файла [random_uuid].txt, а затем удалит этот файл.

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

Процедура стандартна, и это привело к идее создать "готовое решение", которое включает три файла с php сценариями и один файл - лаунчер, fmp12.
Файл-лаунчер, содержит два обязательных макета и набор сценариев для авторизации. Еще в нем есть два вспомогательных макета, один - для демонстрации режима, в котором пользователь прошел авторизацию. Еще один есть, на нем три поля контейнера для хранения PHP файлов. Макеты подогнаны под размеры Samsung Galaxy S6

Этот файл можно использовать двояко. Можно использовать только для авторизации, запуская вслед за процедурой авторизации основной файл. А можно, напротив, сделать его рабочим файлом, добавить таблицы из внешнего файла, создать макеты и прописать логику.

Чтобы связать лаунчер с рабочим файлом, требуется выполнить очень простые процедуры.
1) Прописать рабочий файл в External Datasources
2) Создать акаунт webd / webd в рабочем файле, с доступом в режиме вебдиректа. Можно пароль поменять, но это следует сделать и в лаунчере и в рабочем файле.
3) Скопировать скрипт $_remote_check_account в рабочий файл и предоставить Full Access Privileges
4) Перенастроить лаунчер, чтобы $_remote_check_account выполнялся именно из рабочего файла.

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

========================
Пробуем. Если что не так, или описание кривое, буду дорабатывать.

PS. Лаунчер самодостаточен, в демо-режиме покажет работу, даже если и не соединять его с внешним файлом. Просто разместите php , как написано выше, пропишите привилегии для папки, веб-путь к сценариям php пропишите в кастом функции.
Админский доступ - admin / admin
==================
короче, файлик не цепляется во вложения. типа, слишком жирный. Поэтому ссыль
https://drive.google.com/file/d/14fAHMp ... sp=sharing

Ответить