1

プログラムで WebObjects Web サイトと対話し、応答からデータを抽出する必要があります。私がスクレイピングしている特定の WebObjects サイトは、コンポーネント アクションを使用し、セッションを Cookie (URL ではありません) に保存します。これは、すべての URL が次のようになることを意味します。

http://example.com/WOApp/WebObjects/WOApp.woa/wo/7.0.0.0.29.1.1.1

私の最初の質問は次のとおりです。

  1. このような URL は、ローカルおよび共有のキャッシングの機会 (REST でのキャッシング可能な制約) を完全に破壊しませんか? このような URL を使用した効果的なキャッシュは、WebObjects サーバー自体だけだと思います。
  2. アドレッシング機能も壊れていませんか？各リソースには固有のエンドポイントがありますが、常に変化します。さらに、(私が思うに) WebObjects は、一定期間後に「タイムアウト」するため、古すぎる URL も無効にします。ただし、これがセッションを含む URL にのみ適用されるかどうかはわかりません。

スクレイピングに関しては、Web サイトから意味のあるエンドポイントを抽出できるかどうかはわかりません。たとえば、通常の Web サイトでは、HTML を調べて POST URL を抽出し、通常の要求と応答のサイクルではなく、直接投稿することでスクレイパーで使用します。

この場合、HTML から抽出された URL はリクエストごとに動的に生成されるため、明らかに使用できませんが、セキュリティ設定がこれを許可しないように設定されていない場合、WebObjects コンポーネントに直接アクセスできることについて何かを読みました ( https:/を参照)。 /developer.apple.com/legacy/library/documentation/LegacyTechnologies/WebObjects/WebObjects_3.5/PDF/WebObjectsDevGuide.pdf、p. 53「直接リクエストの制限」)。ただし、これを行う方法、または可能かどうかは正確にはわかりません。

それが不可能な場合、どのようなアプローチが良いでしょうか? 私が考えることができる唯一のオプションは次のとおりです。

  • 本格的なブラウザ クライアントを使用して Web サイト (WatiR や Selenium など) とやり取りし、応答から HTML を抽出して処理する
  • 動的エンドポイントを手動で抽出するには、最初にそれらが存在するページを要求し、次にそれらが配置されている HTML 内の場所を見つけます。その後、それらが「静的」であるかのように使用します。

上記の解決策のいずれも特に優れているとは思わないため、このシナリオにどのようにアプローチするかについての意見に興味があります。

4

2 に答える 2

1

いくつかの質問がありました。それぞれを順番に説明できるかどうかを確認します。

このような URL は、ローカルおよび共有のキャッシングの機会 (REST でのキャッシング可能な制約) を完全に破壊しませんか? このような URL を使用した効果的なキャッシュは、WebObjects サーバー自体だけだと思います。

実際、WebObjects アプリケーション サーバー内にはページ キャッシュがあり、これらのコンポーネント アクション URL がおそらく他の種類のキャッシュを妨害することを観察するのは正しいことです。さらに、セッション ID が URL に含まれていなくても、同じページを再作成するには Cookie にセッション ID が必要になるため、その URLだけを使用すると、アプリケーション サーバーからセッション復元エラーが発生します。

アドレッシング機能も壊れていませんか？各リソースには固有のエンドポイントがありますが、常に変化します。

ええ、そうです、一見するとこれは真実です。例としてコンポーネント アクション URL を指定しましたが、それらはセッションに関連付けられています。

さらに、(私が思うに) WebObjects は、一定期間後に「タイムアウト」するため、古すぎる URL も無効にします。ただし、これがセッションを含む URL にのみ適用されるかどうかはわかりません。

繰り返しますが、すべて真実です。コンポーネント アクション URL によってセッションが生成され、セッションがタイムアウトします。

この時点で、簡単な転用をさせてください。あなたは WebObjects アプリケーションの所有者ではなく、WebObjects アプリをスクレイピングしなければならないという話で、この特定のアプリが REST 原則に準拠していないいくつかの方法を特定したと思います。おっしゃる通り、完全にコンポーネント アクション ベースの WebObjects アプリケーションは RESTful にはなりません。WebObjects は REST よりも数年前から存在します。そうは言っても、WebObjects アプリケーションを完全にRESTfulにする方法はいくつかあります。

  • セッションのないダイレクト アクションを使用すると、REST に似た動作が得られ、キャッシュ、アドレス指定可能性、および有効期限に関して特定した問題が確実に解決されます。
  • ERRest フレームワークを使用して 100% RESTful アプリケーションを作成します。

もちろん、レガシー アプリケーションをスクレイピングしようとしているだけの場合、これは役に立ちません。

スクレイピングに関しては、Web サイトから意味のあるエンドポイントを抽出できるかどうかはわかりません。たとえば、通常の Web サイトでは、HTML を調べて POST URL を抽出し、通常の要求と応答のサイクルではなく、直接投稿することでスクレイパーで使用します。

繰り返しになりますが、完全にコンポーネント化されたアクション ベースのアプリケーションであれば、その通りです。これらの URL はすべて動的に生成され、役に立たなくなります。

この場合、HTML から抽出された URL はリクエストごとに動的に生成されるため、明らかに使用できませんが、セキュリティ設定がこれを許可しないように設定されていない場合、WebObjects コンポーネントに直接アクセスできることについて何かを読みました…</p>

これは、いくつかの制限付きで、コンポーネントをテンプレートから直接レンダリングすることについて話しています。

  • お気づきのように、アプリケーションはそれがまったく起こらないように簡単に防ぐことができます.
  • p.53 で述べたように、コンポーネントをレンダリングするユーザー入力とアクション呼び出しフェーズはスキップされます。これはおそらく、このアプローチが動的コンテンツを持たないコンポーネントのレンダリングに限定されることを意味します。関心のあるコンポーネント名を知る必要がありますが、通常はどこにも公開されません。

Selenium を使用したブラウザー レベルでの自動化など、既に上で提案した高レベルの機能的アプローチの種類よりも優れたものを見つけることができるかどうかはわかりません。アプリケーション内のリソースの REST スタイルの直接アドレス指定可能性が必要な場合、アプリケーションを書き直して、必要な場所で直接アクションまたは ERRest を使用できるようにしない限り、それは得られません。

于 2014-02-19T09:18:51.870 に答える
0

少し遅れましたが、役に立ちます。

Apache の mod_ext_filter (少し変更) を使用して、WebObjects アプリケーションからの要求/応答を事前/事後フィルター処理します。フィルターは PHP スクリプトを呼び出し、HTML ページから動的なハイパーリファレンスやその他のものを読み取ることができます。スクリプトは HTTP 要求を変更することもできるため、要求からパラメーターをプログラムで追加/削除して、レガシー アプリの前に新しいワークフローを実装し、WebObjects に到達する前に要求をクリーンアップできます。スクリプト内で追加のデータベースを処理し、複数のリクエストにわたっていくつかのものを保存することもできます。

したがって、動的に作成されたリンク (おそらくボタンの名前または HTML フォームの宛先) を取得し、要求内でこれらの名前を認識することができます。

「ページの 3 番目のボタンをクリックする」などの小さなスクリプトを使用して、このようなアプリケーションを「リモート コントロール」することもできます。必要なのは、HTML ページの構造を取得し、ブラウザが実行するアクションを再構築する DOM パーサーだけです (つまり、HTTP 要求を手動で作成し、抽出されたフォームの宛先 href に POST として送信します)。唯一の問題は Javascript コードです。これを分析し、PHP 内で再プログラムします (つまり、入力要素を有効/無効にするため、リクエスト内で送信されません)。

WebObjects Adapter Module for Apache 内にいくつかの問題がありました。HTTP ヘッダー内で引き続き Content-Length を使用しますが、これは mod_ext_filter で変更できません。リクエスト内の HTML またはパラメータを変更すると、コンテンツの長さが一致しなくなります。しかし、それを変えることは可能です。

理論的には、このようなクローズド ソースのレガシー アプリケーションをタブレットやスマートフォンの新しい UI から制御することも可能です。これにより、ユーザー インタラクションがバックエンドの WebObjects アプリに委任されます。

スクリプトはページ構造に依存するため、WebObjects アプリが変更される場合は、スクリプトの一部を修正する必要があります (つまり、3 番目のボタンが 4 番目のボタンになる可能性があります)。

また、アプリケーションの前に Restful インターフェイスを追加し、フィルター スクリプトによってレガシー アプリからデータをクエリすることも可能です。

于 2019-01-28T13:14:02.807 に答える