一方、ダービーには独自のハブがあります。
今日は、認証とデータへのアクセスの制限についてお話します。 everyauthまたはパスポートを使用する方が良いでしょうか？ 認証の追加は難しいですか？ データへのアクセスを制限する方法は？ 1つのダービーアプリケーション内でユーザー用のアプリケーションと管理パネルを分離する方法
ログイン
Derby-examplesには、 everyauthで承認されたサンプルアプリケーションがあります 。 ご覧のとおり、twitter、facebook、linkedin、githubなどを介して承認を実装するのは非常に簡単です。 しかし、リンクダービー+ everyauthには、everyauthがexpressに強く結び付けられているという事実のために、login-passwordを介した許可に関して特定の問題があります。 everyauthはderbyの作成者の1人 （derbyよりずっと前）によって作成されましたが、このモジュールをderby専用に使用することは完全に便利ではありません。 それは人生で起こります。 したがって、推奨事項はpassportを使用することです。passportは 、そのアーキテクチャにより、ダービーにより適しています。 ほとんどの場合、 derby-authを使用できます。これは、パスポートに実装された既製の認証モジュールです。 ご覧のとおり、2つのコレクションが作成されます：auth-ユーザーパスワードが存在する場所とusers-他のユーザーデータが存在する場所。 なぜ2つのコレクションなのか？ 現時点では、ダービーでは、エンティティのフィールドへのアクセスを制限する方法はありません（エンティティは、idを持つデータベース内のオブジェクトです）。 エンティティ全体またはコレクション全体に対してのみ。 これは、share.jsの制限によるものです。 つまり、同じユーザーコレクション内では、ユーザーが他のユーザーの名前を表示することを許可することはできず、同時に、パスワードを表示することもできません。 したがって、2つのコレクションが必要です。 これはおそらくダービーの瞬間で最も不快な瞬間であり、もちろん将来修正されるでしょう。
データアクセス制限
racer-accessモジュールを使用して、データベースレベル（より正確には、ormレベルまたはストアオブジェクト）でデータへのアクセスを制限できます。 その中で、接続からのセッションを使用してユーザーを識別できます。 このように使用します：
var racerAccess = require('racer-access'); derby.use(racerAccess); store.allow('change', 'users', function (some usefull arguments) { return true || false; });
derby.use-これはプラグインがダービーに追加される方法です。
store.allow-これは、データへのアクセスを制限するルールを設定する方法です。 この場合、ルールはユーザーコレクションを変更することです。 返される引数はルールによって異なり、特に接続セッションが含まれます。 関数はboolを返します-アクセスは許可されているかどうか。
racer-accessに関するドキュメントはありませんが、 ソースコードは小さく、読みやすく、コメントが含まれています。
クライアントアプリケーション
承認を行い、データへのアクセスを制限しました。 しかし、テンプレート、スタイル、ロジックを管理パネルからユーザーのブラウザーに送信したくない場合はどうでしょうか？ クライアントアプリケーションをいくつかに分割できます。 アプリとログインの2つのクライアントアプリケーションの例があります。 そして、 これはサーバー上のオブジェクトの形式です。
login = require('../login') main = require('../app')
それらのテンプレート、スタイル、jsは、それぞれ/ views / app-/ views / login、/ styles / app-/ styles / login、/ lib / app-/ lib / loginフォルダーにあります。 ブラウザは、いずれかのアプリケーションをロードします。 これは、セキュリティの観点だけでなく、トラフィックの削減という点でも便利です。
ダービーコンテンツ
更新：彼らはまだderby-authに基づいて作成されたderby-passportがあることを示唆しました