ここでは、
GeneXus 17 Upgrade 4 に含まれるアップロードメカニズムの重要な変更について、簡単に説明します。
これらの変更のいくつかは、GeneXus コードと、生成したソリューションのインターフェースの互換性に影響するため、理解しておくことが重要です。
GeneXus では、次の方法でファイルがサーバーにアップロードされます。
- Web パネルで、FileUpload ユーザーコントロール、またはファイルアップロードが可能な別のコントロールを使用して実行します。
- Web パネルで、画面上で Blob 変数を使用して実行します。
- トランザクションで、Blob または Multimedia タイプ (Audio、Video、Image、BlobFile) の項目属性を使用して実行します。
- トランザクションと関連付けられている Work With for Smart Devices のレイアウトで、Blob または Multimedia タイプの項目属性を使用して実行します。
- プロシージャー、ビジネスコンポーネント、あるいは Blob または Multimedia タイプのパラメーターを (変数、項目属性、または SDT フィールドとして) 受け取る REST インターフェースを持つ API を使用して実行します。
- パネルで、画面上に Blob 変数を配置して実行します。
通常、このアップロードは、特にクライアント側とサーバー側がナレッジベース自体のオブジェクトで開発された場合、GeneXus で自動的に処理されます。
4 番のように、外部システムとの連携や、ほかのユーザーコントロールの開発など、既存のメカニズムと関連する場合については、Wiki に詳細が記載されています。
1、4、5、および 6 番の場合、ファイルアップロードは「/gxobject」URL を呼び出して実行します。2 および 3 番の場合は、アップロードコントロールが配置されたオブジェクトによってマルチパート POST が実行されます。
セキュリティを強化するため、すべてのアップロードメカニズムに変更が加えられました。これは主に内部的な修正ですが、5 番の場合は特に、一部のシナリオで互換性に影響があります。
新しいメカニズムには、主に 3 つの変更が含まれています。
- ファイルをアップロードするときに呼び出されるエントリーポイントの変更
- サーバーにアップロードされたファイルの物理名の変更
- アップロードされたファイルを処理する内部メカニズムの変更
前述の 1、4、5、および 6 番に影響します。
概念レベルでは、Web アプリケーション全体で汎用的に使われるエントリーポイントではなく、オブジェクトごとに 1 つのエントリーポイントが使われます。そのため、オブジェクトのほかのエントリーポイントと同様に、セキュリティについてもオブジェクトが制御するようになります。
具体的に言うと、サービスは「/gxobject」の下ではなく「/<オブジェクト名>/gxobject」の下になります。ここで、「オブジェクト名」はオブジェクトが URL を介して呼び出されるときの名前になります。
例: URL が https://example.com/MyWebPanel.aspx の場合、アップロード用のサービス URL は https://example.com/MyWebPanel.aspx/gxobject になります。
認証とオーソライズも、該当するオブジェクトの GAM の設定によって制御されます。オーソライズを得られなかった場合は、HTTP ステータスコード 403 が返されます。
セキュリティが強化される前のメカニズムを維持したい場合は、
こちらの記事を参照してください。
注: 2 および 3 番の場合、オブジェクトと関連付けられたサービスへのマルチパート POST が以前と同じように実行されます。また、オブジェクト自体の GAM 設定も以前と同じです。これについては変更がありません。
サーバーに物理的にアップロードされたファイルには、GUID 名と拡張子 tmp が付けられます。データを失うことなく適切に処理できるように、元のファイル名と拡張子だけでなくファイルへの参照も、別の GUID であるキーを使用してキャッシュに格納されます。
このキャッシュ参照は 10 分間のみ有効です。
2 つのケースがあります。
ファイルがトランザクション以外のオブジェクトでアップロードされた場合、クライアント側は POST 応答として文字列 gxupload:<GUID> (アップロードされたファイルへの参照) と、アップロードされたファイルの元の名前および拡張子を受け取ります。
サーバー側イベントでは、この参照を GeneXus File タイプ変数の [ Source ] プロパティに割り当てることができます。この File タイプの変数はファイルをポイントしますが、その名前と拡張子を照会すると、(<GUID>.tmp ではなく) 元の名前と拡張子が取得されます。そのため、ファイルが期待したタイプであるかどうかを検証したり、そのファイルを開いたり、コピーしたり、何らかの方法で操作したりできます。
ファイルがトランザクションでアップロードされた場合、項目属性が Blob タイプか Multimedia タイプかによって処理が異なります。また、Blob タイプである場合、 [ FileType Attribute ] プロパティと [ FileName Attribute ] プロパティが設定されているかどうかによっても処理が異なります。
Blob タイプの項目属性で、 [ FileType Attribute ] プロパティと [ FileName Attribute ] プロパティが設定されている場合、アップロードされたファイルの名前と元の拡張子が項目属性に格納されます。そのため、名前と拡張子が有効であるかどうかを確認し、有効でない場合はトランザクションを保存する前にエラーを表示できます。
レコードが保存された場合、このファイルは、アップロードされたときのファイル名および拡張子でダウンロードされます (名前の衝突を防ぐため、中に GUID が追加されます)。
Blob タイプの項目属性で、 [ FileType Attribute ] プロパティと [ FileName Attribute ] プロパティが設定されていない場合、ファイルの元の名前と拡張子は維持されずにファイルがアップロードされます。また、ダウンロードされたファイルの名前には GUID と拡張子 tmp が付けられます。
Multimedia タイプの項目属性の場合、ユーザーは、アップロードしたファイルのデータ、拡張子、および名前を変更する前に、項目属性の [ ImageType ] プロパティまたは [ ImageName ] プロパティを問い合わせることで、それが Image タイプであるかどうかを確認できます。Video、Audio、および BlobFile データタイプについても、類似したプロパティが存在します。
前述の内部的な変更は、次に説明する場合を除いて互換性には影響しません。
GeneXus で開発したソリューションにファイルをアップロードする際に、ほかのシステムを使用する場合、前述のエントリーポイントの変更を考慮する必要があります。
Web パネルにファイルをアップロードするユーザーコントロールは、ファイルを受け取るための独自のサーバー側メカニズムを提供する必要があります。ファイルを受け取るためのエントリーポイントは、レイアウトに File Upload コントロールがある場合にのみ生成されます。
ファイルのアップロード後、アップロードされたファイルをポイントする変数 (通常は &FileUploadData) の [ File ] プロパティは、ファイルのパスではなく、ファイルへの参照を返すようになります。
&Client がビジネスコンポーネントで、ClientImage が Image タイプのフィールドである場合、次の行には互換性の問題が
ありません。
&Client.ClientImage = &FileUploadData.File
&Client.Save()
しかし、アップロードしたファイルを外部プログラムで処理する必要がある場合、次の例では問題が生じることがあります。
EXO.ProcessFile(&FileUploadData.File)
問題を解決するには、
File データタイプの補助変数にアップロードされたファイルへの参照を割り当てます。
&File.Source = &FileUploadData.File
EXO.ProcessFile(&File.GetURI())
注: 元の名前と拡張子を取得するには、&FileUploadData の FullName、Name、または Extension フィールドを読み取ります。
Knowledge Base Navigator を使用する場合は、それが GeneXus のバージョンに対応していることを確認してください。対応していないと、ファイルのアップロード時に次のようなエラーが表示されることがあります。
There was an error executing action
not found
この場合、Knowledge Base Navigator がサポート対象ではない 以前のバージョンの環境を使用しています。