Qodly Studio for 4D による 4Dクライアントライセンス消費方法の改善
Qodly Studio for 4D を使い始めた方は、ビジネスWebアプリケーションの開発をするのにこの新しいツールがどれだけパワフルかすでにご存知でしょう。まだ使い始めていない方は、こちらをご覧ください。
Qodly Studio for 4D で作られたアプリケーションは、REST API に依存しています。4D 20 R5 には素晴らしい新機能が搭載されています: “強制ログイン” モードです。
強制ログインモードでは、ユーザーがログインに成功し、アプリケーションのデータやロジックを操作し始めた時のみ、4Dクライアントのライセンスが消費されます。
続きをお読みください！ デモのダウンロードもお忘れなく！
スケーラブルなウェブセッションによるサーバー上でのデバッグ
スケーラブルWebセッションは、4D v18 R6でもたらされた重要な改良点です。これにより、4Dタグ、4Dアクション、REST APIを、4Dサーバー上で、インタプリタモードでも、プリエンプティブなプロセスで使用することができるようになりました。しかし、このようなプログラムをデバッグするには、プリエンプティブプロセスではデバッガーウィンドウを開くことができないため、サーバー上で開発環境を開き、協調モードに切り替えさせる必要があったのです。このように、v19 R2までは、REST、4Dアクション、4Dタグのデバッグが可能でした。v19 R3からは、これらすべてが簡単になり、通常通りデバッガをアタッチするだけでサーバーサイドのデバッグができるようになりました。
cookie の新しい SameSite属性 と Secure属性
Cookie の機能は長年にわたって成長し、進化してきましたが、いくつかのレガシー問題を残しています。これに対処するため、ブラウザー (Safari、Chrome、Firefox、Edge を含む) は、SameSite属性と Secure属性に関する動作を、cookie の secure-by-default モデルのために変更しています。
4D Webデベロッパーとして、クロスサイトリクエストフォージェリ からアプリケーションを守りたい場合、4D Webセッションの セッションcookie について懸念されるかもしれません。
Webセッションcookie が Web上で無意味に流通したり、適用されたデフォルト値のためにブラウザーに誤解されたりするのを防ぐためには、cookie の種別を確認すべきです:
- サードパーティーcookie: 訪問したページとは異なるドメイン名に関連付けられた cookie。サードパーティーcookie は、ページをホストしているドメイン以外のドメインから供給されたページオブジェクト (広告など) によって設定されます。
または
- ファーストパーティーcookie: 訪問したページのドメインに関連づけられた cookie。
ケースに応じて、Webセッションcookie の SameSite 属性に適切な値 を選択する必要があります。
セキュリティを強化するためには、接続がセキュア (HTTPS) であるときに Webセッションcookie に Secure属性を設定し、cookie が安全に送信できることをブラウザーに示す必要があります。
Web上のプライバシーとセキュリティを向上させるために、4D がどのように役立つかを続けて説明します。
高度な Webアプリケーションに対応したスケーラブルセッション
Webアプリケーションは現代に不可欠なツールです。マシンとプロセッサーがより強力になるにつれ、Webアプリケーションは常にパフォーマンス要件を満たさなくてはなりません。4D v18 R6 で、4D Webサーバーが新しいタイプの Webセッション、スケーラブル Web セッション を提供するのはこのためです。
では、詳しく見ていきましょう。
4D RESTセッションの理解を深める
以前のブログ記事で、4D RESTサーバを始める方法を紹介しました。Postmanを使った様々なCRUDオペレーションを紹介し、RESTの完全なドキュメントを紹介しました。今回のブログでは、4Dでセッションがどのように機能するかを説明します。この理解によって、4D RESTサーバを使用してセッションベースの認証システムを構築することができるようになります。