ウェブサイトCMSに最適な場所
私の仕事の一環として、私は最近、ウェブサイト用の多数のコンテンツ管理システムの作成を開始しました。非常に多くのことが明らかになったので、明らかに私の次のステップは、クライアントのニーズに合わせて要素をすばやく削除または追加できるように、Webサイトの「テンプレート」を設定することでした。
基本的に、私はCode Igniterを選択し、フロントエンドにプラグインする準備ができました。
以前は、WebサイトCMSをそのサイトのサブディレクトリに配置していました。たとえば、mysite.com/cmsです。ただし、 'spaghetti' PHPを使用していました。
CIやMVC構造などのフレームワークを使用して、サブドメインでホストするか、フロントエンドとバックエンドを同じアプリケーションに保持するか、別々のドメインに分割するのがよいでしょうか？それとも本当に重要ではないのですか？
それとも本当に重要ではないのですか？
この。結局のところ、どこに配置しても、CMSからほぼ同じパフォーマンスが得られます。機能が重要です。
あなたのビジネスニーズに依存することをお勧めします。
別のドメインを使用すると、アプローチを標準化し、CMSをWebアプリケーションから分離し、サイト管理を単一の場所に集中させることができます。
Content Managentをサービスとして提供し、標準でありながら柔軟なオプションを提供することでビジネスを構築することを想定している場合は、個別のホスティングが適しています。
顧客/クライアントがCMSを所有または制御したい場合、サブドメインアプローチの方が適している可能性があります。
サイトに顧客の関与がほとんどない場合は、CMSとWebサイトを組み合わせて機能します。自分で更新を行うことがめったにない場合、顧客がCMSを削除、移動、または「破る」リスクはありません。
オーサリングのニーズと機能は間違いなく重要ですが、このアプローチはビジネスモデルにも適合する必要があります。
エンドユーザーの観点から見ると、すべてが期待どおりに機能し、問題なくアクセスしている限り、CMSを公開するアドレスは問題ではありません。
開発者の観点から（そして私も多くを書いて公開しました）フロントエンドと同じ物理的な場所で公開するのが少し便利で、URLをフロントと同じレベルに保ちます-「コンテンツの管理」このようにして、フロントエンド生成アプリケーションとCMSの両方に同じ構成ファイルを使用できます（または、別々のファイルである必要がある場合、少なくともそれらの大部分を同じに保ちます）。また、異なるルートを指す相対パス。これは世界の終わりではありませんが、ほとんどの場合、もう少し作業が必要になります。
セキュリティの観点からただし、少し注意が必要です。 CMSへの容易に認識可能なURLパスを使用することは、潜在的にはるかに多くの直接攻撃に対処することを意味し、ブラインド推測に反応する時間がなく、URLスキャナーが悪意のあるリクエストでCMSに到達する前であってもブロックします。 Webアプリケーションのセキュリティプロトコルに自信があり、場合によってはそれが望ましい場合もあります（Webアプリisがハニーポットの場合）。そうではなく、外部管理ハニーポット（セキュリティサーバーmod、ログアナライザーなど）に依存している場合は、CMSの非自明なURLを決定することをお勧めします。 to 'script kiddie'要求を入力し、ブロックします。この後者の場合、CMSユーザーが外部URLを開くなど、すべての外部リクエストを 'anonymize'することをお勧めします。 （CMSの場所）がサードパーティのWebサーバーログに表示される場合があります。外部リクエストを委任できる 'anonymizer'スクリプトの作成は非常に簡単で、CMSメインテンプレートで単一のJS関数呼び出しのみを実行します。サポートを有効にします。
意味...
これをすべて念頭に置いて、CMSをフロントエンドルートに対して相対的な（平行な）同じレベルの非自明なURLでホストすることをお勧めしますが、開発者/設計者とデバッグの利便性のために物理的に同じ場所に配置します目的、およびいくつかの「隠蔽によるセキュリティ」、少なくとも最も明白な 'crude'をキャッチするのに十分危害を加える前に比較的簡単に。もちろん、 'obscurityによるセキュリティ'だけに依存してはならず、前者が失敗した場合は常に他のプロトコルを使用する必要があります）。
乾杯！
別のドメインに保存することをお勧めします。または、同じドメインにCMSを配置する場合は、Blogger.comやworpdressなどの強力なドメインに保存します。