Comments 35
Вход через Гугл не работает.
Регистрация пользователя через гугл включает в себя шаг подтверждения емейла по приходящему токену. Это сделано для всех соц сетей, чтобы иметь в результате один пользовательский профайл сразу, а не объединять разные. Проверьте пожалуйста пнишло ли вам письмо с токеном. Затем введите значение токена в форму регистрации. После этого можно логиниться с помощью гугл аккаунта.
Письмо пришло, токен ввел. Но не пускает. Пришлось воспользоваться кнопкой сбросить пароль и войти по логину и паролю.
Но в любом случае. Вход через Гугл не должен присылать на почту, принадлежность почты и так подтверждается. А что касается объединения нескольких учеток, то их можно объединять по email. Вы перемудлили, там где не надо, а там где надо (интефс редактирования страниц/воркфловов не доделали).
"Вход через Гугл не должен присылать на почту, принадлежность почты и так подтверждается." - да, но: буквально вчера я вводил токен отправленный мне на гугловую почту гуглом работая с одним из сервисов гугл.
Это зависит от "точки зрения". Данная реализация позволяет привязать OAuth аккаунт к любому е-мейлу на данном сайте. Привязка осуществляется не по е-мейлу, а по идентификатору. Поэтому у пользователя запрашивается е-мейл, к которому пользователь собирается подключить OAuth аккаунт. Это то, что касается гугла. Касательно других OAuth провайдеров - никто не гарантирует, что пользователь скажем регистрировался на GitHub - Если вы доверяете ваш аккаунт OAuth провайдеру гугла, это не значит, что вы доверяете ваш аккаунт GitHub. Другой пользователь "теоретически" может зарегистрировать аккаунт на другом OAuth провайдере и далее зайти в ваш профиль уже на данном сайте. По этой причине токен высылается каждый раз, для всех OAuth провайдеров. Я понимаю, что гораздо удобнее для пользователя, когда его новый профайл создается совершенно прозрачно (и диалог кажется перегруженным, но есть и плюсы данного подхода), но в данном веб приложении пользователь согласно бизнес-логике веб приложения должен согласиться с лицензионным соглашением, поэтому это вынесено в один диалог. На практике предполагается, что это делается один раз, больше пользователь к данному диалогу не возвращается. Также обратите внимание, данное веб приложение позволяет "удалить" пароль. Следующая аутентификация будет возможна только через OAuth провайдера или через форму восстановления пароля пользователя. Возможно вам будет полезна эта информация, позволит вам взглянуть иначе на данную тему.
Пофиксил.
Вообще, конечно, больше парсеров богу парсеров. Успехов и процветания.
Однако, опыт сотен аналогичных проектов давно показал, что не взлетает, т.к. для мелких клиентов это совсем не лоукод, крупные предпочитают готовый датасет, а для прогеров это недоязыг и лучше бы обычный js например.
1) Мелкие клиенты могут заказать создание парсера на основе данного сервиса; 2) переиспользовать один из имеющихся для целевого маназина на рснове шаблона типа OpenCart, Shopify и других - пример доя шопифай приведен; 3) Можно создать набор команд для продвинутых пользователей включающих в себя интерпретатор языка программирования javascript - это впишется в архитектуру проекта.
чегото мне показалось что мелкий клиент который в этом всём разберётся сможет самостоятельно всё это/parsing сделать ну или на крайняк пустить какой-нибдь вебsnake чтобы локально уже отдолбить собраное - незнаю кому надо это на регулярной основе чтобы не заниматься автоматизацией
1) Мелкие клиенты могут заказать создание парсера на основе данного сервиса;
Кому заказать? Тому, кто сам себе селениум? Зачем ему ваш SaaS? А для сына маминой подруги есть (десктопные бесплатные) продукты с визуальным программированием (или js - на выбор) того, что вы называете workflow.
2) переиспользовать
Та же проблема → для барыги - конечного пользователя это слишком сложно, для прогера слишком неудобно.
3) Можно создать набор команд для продвинутых пользователей включающих в себя интерпретатор языка программирования javascript
И зачем продвинутым ваша прокладка к селениуму? Они и без вас гоняют его хоть в js, хоть в питоне.
Ну реально же, сотни аналогичных сервисов. Чем ваш лучше?
Уникальность данного сервиса в выстроенном балансе между удобством и сложностью. Оценивать данный сервис стоит интегрированно: давать интегрированную оценку за и против. Зачем делать магазин на шаблоне если можно заказать у сына подруги самопис или зачем делать самопис, если можно взять готоввй магазин на основе шаблона - это подобная задача ввбора - всем находится место под Солнцем. В данном случае, стоит рассматривать данный сервис, как интегрированное программное решение. "Недоязык" - лучшая практика из "кровавого энтерпрайза". Процедурный подход из 70-х - лучше чем функционалтное программирование для подобного рода задач. Кесорю - Ксорево.
Честно, я думал, что зайду и наклепаю простой парсер за пару минут. Но что-то не пошло. Слишком кривой ui. Например, зачем подтверждать создание объекта? Меня прям выбесило. Потом, после создания в него нужно зайти, что бы редактировать. Для POC нужен удобный интерфейс, а он совсем не удобный. Импорта/экспорта я не увидел там. Либо его нет, либо не нашёл из-за кривого интерфейса.
Да, на создание можно убрать подтверждение, после создания открывать на редактирование объект.
Импорта-экспорта нет (всего проекта) пока - потому, что это MVP. Но есть возможность сохрвнить исходный код Flow открыв его в виде json. Можно "всё" доделать, но выйти на рынок с седой бородой.
Поправил, как вы указали - для повышения удобства использования. Импорт-экспорт позже - это не 5 минут работы :)
балансе между удобством и сложностью
Для кого? Неужели для
"кровавого энтерпрайза" ?
Сам ставлю на то, что нормальный офисный планктон хочет кнопку Сделать красиво и совсем не имеет времени и желания разбираться, учиться, отлаживать, поддерживать ..
И ведь (говорят) хорошо идут готовые специализированные парсеры для shopify, amazon и т.п.
Подход работы с Workflow распространенный. Приведу пример. Всегда можно все сделать на хранимых процедурах, но клиенты выбирают SQL Server Integration Services, чтобы иметь "отраслевое решение". Другой пример, люди используют Wix, Tilda, Elementor, хотя существует Bootstrap 5, Tailwind, PrimeFlex. Инженеры склонны выбирать профессиональные инструменты для решения задач. Java бэкенд разработчики могут выбрать Vaadin, а не Angular или React для создания пользовательского интерфейса. Людям в деловых костюмах нравятся "стандартные", то есть шаблонные подходы к решению задач, когда решение задачи "испортить сложно", можно отдать проект на сопровождение другому специалисту. Это возможно благодаря "недоязыкам" - вставил картридж и все работает. Данный парсер может легко освоить ученик 10-го класса, который не является еще инженером программистом - это открывает для людей новые возможности, создаёт "АЙТИ для всех", а не только для инженеров, так как персональные компьютеры и мейнфреймы. Дети массово в школах изучают работу с офисными пакетами, но не Linux Console.
создаёт "АЙТИ для всех"
Создается впечатление, что вы не в курсе, что все это давно создано 100500 раз.
Вот, например, школьники реально обожают. Но прочие перечисленные почему-то не пользуются)))
Когда я был "школьником" я смотрел в сторону "визуального редактора веб интерфейсов", сейчас предпочитаю верстать руками. Как объяснить всем пользователям, купившим Vaadin и MS SSIS, что есть лучшее решкние. Я понимаю, что двнная реализация не тянет на майкрософт интегрейшен сервис, но я один раз написал алгоритм копирования данных для одного из шаблонов Shopify и теперь этим могут пользоваться люди. Следующий алгоритм я сделаю для шаблона OpenCart и подробно опишу как он устроен и выложу в открытый доступ. Конечному пользователю может быть ближе и роднее слово "картридж" или "кассета", чем библиотеки Python.
Не согласен, лучшие решения сочетают в себе 2 крайности, а не баланс. В целом сложно представить себе успешный парсер в виде сервиса. Мне кажется его можно сделать только на основе ИИ. Типа заходишь вместе с ним и объясняешь ему что нужно делать.
С этим конкретным проектом это покажет воля комьюнити и усилия затраченные на проект. Одну правку я уже внес, спасибо вам за рекомендации. Да, этот проект временный в перспективе развития возможностей искусственного интеллекта, как и многие другие программные продукты. Но кто-то должен тоже объяснить что и как нужно сделать...
deleted comment
Что под капотом?
Как обходите user-agent check?
Используете несколько прокси?
Как с captcha? Поддерживается?
Antibot типа datadome.co обходите?
Под капотом работа через Selenium Web Driver. Парсер проверяет robots.txt и исходя из этого принимает решение о возможности продолжения работы. Обход капчи не планируется. Парсер союлюдает этикет работы в сети Интернет.
Сейчас прокси нет. Будут добавлены по мере развития проекта.
Название сервиса созвучно с сеошным десктопным Screaming Frog SEO Spider, в котором также есть возможность извлечения данных.
Полагаю, Фрог в названии это лишь случайное совпадение )
Плюс, в аналогичном бесплатном SiteAnalyzer все это также есть с возможностью парсить через XPath, CSS, XQuery, Regexp.
Ну и пока десктоп решения по парсингу все-таки выглядит предпочтительне, чем веб, т.к. на ПК по сути нет ограничения в потоках + хранение данных дано на откуп пользователю. Т.е. как минимум не нужно за это платить, как в веб-сервисах.
А для парсинга реально больших объемов сайтов я бы обратился в специализированные сервисы, коих достаточно. Из соображений надежности и чтобы не морочиться вручную с настройками и прочим.
ИМХО
+ подписка в долларах. Ну такое себе. Вам бы для начала на русскоязычных юзверях откатать.
+ голый сервис без полноценного сайта и инфраструктуры - никто не найдет в поиске, соотв. с монетизацией будет сложнее, чем могло бы быть.
В целом, идея наверное интересная, хотя тут нужно понимать рынок, и возможно что ниша давно занята аналогами, работающими в стиле - списался, дал им ТЗ, оплатил деньгу - они спарсили все что нужно и прислали готовый Excel, без танцев с бубном с настройками.
Frog Parser — Парсинг Web страниц без сложностей