問題タブ [wshttpbinding]

SQLAzureデータベースにアクセスするAzureでホストされている一連のWCFRESTサービスを用意します。ServicePointManager.UseNagleAlgorithmがtrueに設定されていることがわかります。これをfalseに設定すると、テーブルストレージへの呼び出し（1460バイト未満のレコードの挿入）が高速化されることを理解しています。次のリンクで説明しています。

私の質問-Nagleアルゴリズムを無効にすると、SQL Azureへの呼び出しも高速化されますか？

WCF サービスで動作するトランスポート セキュリティでユーザー名認証を取得するために、このチュートリアルに従っています。ただし、チュートリアルでは、 basicHttpBindingwhich is unacceptable - I requireの使用について言及していますwsHttpBinding。

BasicAuthenticationModuleアイデアは、HTTP 要求から「Authorization」ヘッダーを読み取り、「Authorization」ヘッダーの内容に従って認証プロセスを実行する WCF サービスのカスタムを持つことです。問題は、「Authorization」ヘッダーが欠落していることです!

IClientMessageInspector発信メッセージを操作し、カスタム SOAP ヘッダーを追加するために、カスタム動作を実装しました。BeforeSendRequest関数に次のコードを追加しました。

これは機能するはずであり、多くの Web リソースによるとbasicHttpBinding、wsHttpBinding. 「動作する」とは、WCF サービスがヘッダーを正常に受信したことを意味します。

これは、WCF サービス側で受信した HTTP メッセージを検査する単純化された関数です。

2011 年 9 月付けのこのスレッドの下部の投稿では、これは では不可能であると述べていwsHttpBindingます。私はその返事を受け入れたくない。

補足として、IIS に組み込まれている基本認証モジュールを使用し、カスタム モジュールを使用しないと、次のようになります。

The parameter 'username' must not include commas.**Roles.IsInRole("RoleName")または `[PrincipalPermission(SecurityAction.Demand, Role = "RoleName")]を試行したときのエラー メッセージ

おそらく、証明書ベースのメッセージ セキュリティでセキュリティをPrimaryIdentity.Name使用しているため、プロパティに証明書のサブジェクト名が含まれているためです。TransportWithMessageCredential

問題に対する代替アプローチだけでなく、提案も受け付けています。ありがとう。

アップデート

お分かりのように、HTTP ヘッダーは、後で WCF サービス コード全体で正しく読み取られます。 (HttpRequestMessageProperty)OperationContext.Current.IncomingMessageProperties["httpRequest"]カスタムヘッダーが含まれています。ただし、これは既にメッセージ レベルです。トランスポート認証ルーチンにヘッダーを渡す方法は?

更新 2
少し調査した結果、Web ブラウザーが HTTP ステータス コード 401 を受信すると、資格情報を指定できるログイン ダイアログが表示されるという結論に達しました。ただし、WCF クライアントは単に例外をスローし、資格情報を送信したくありません。https://myserver/myservice/service.svcInternet Explorer でアクセスしたときに、この動作を確認できましたこのリンクからの情報を使用して修正しようとしましこれは WCF のバグですか、それとも何か不足していますか?

編集

これが私のsystem.servicemodel（からのweb.config）関連セクションです - 私はそれを正しく設定したと確信しています。

サービスによって返される例外は次のとおりです。

HTTP 要求は、クライアント認証スキーム「匿名」では許可されていません。サーバーから受信した認証ヘッダーは「Basic Realm,Negotiate,NTLM」でした。(リモート サーバーがエラーを返しました: (401) Unauthorized.)

SOAPエンドポイント（wsHttpBinding）とRESTエンドポイント（webHttpBinding）を介して公開する必要があるWCFサービスがあります。バージョン管理を支援するために、関連する属性に名前と名前空間を含めました（tempuri.orgはWSDLから完全に削除する必要があります）。何らかの理由で、webHttpBindingエンドポイントにbindingNamepace属性を追加しないと、WSDLにtempuri.org名前空間が追加されます。WSDL出力の例を以下に示します。

bindingNamespaceのないWSDL-

bindingNamespaceを使用したWSDL-

これがエンドポイントのweb.Configです。WCFExtrasを使用してWSDLをフラット化します（したがって、wsHttpBindingエンドポイントのbehaviorConfiguration）が、それがなくても動作は同じです。

ソリューションにWCFExtrasをロードし、WsdlExporterを調べて、tempuri.orgの言及が成功しないかどうかを確認しました。また、XSharper.Coreを使用してオブジェクトグラフをダンプし、それが見つかるかどうかを確認しました。ありません。

誰かがこれを以前に経験したことがありますか？回避策として、WSDLをクリーンに保つためにwebHttpBindingエンドポイントにbindingNamespaceを含めますが、これが発生する理由を知りたいと思います。

ありがとう！

wsHttpBindingとそれを呼び出すクライアントを使用するWCFサービスを構築しました。
しかし、それでも次のエラーメッセージが表示されます。

内部の例外は次のとおりです。

これがサービスの設定ファイルです：

クライアント設定ファイルは次のとおりです。

問題のある構成は、negotiateServiceCredential="false"です。
サービスとクライアントの両方でtrueに設定すると、クライアントは完全に機能します（この変更を除いて、上記の構成ファイルを使用します）

誰かが私がここで何が恋しいのか教えてもらえますか？

前もって感謝します。

私は一日中WCFのセキュリティについて読んでいて、それが快適だとは言えません。

いくつかのWCFサービスを開発し、それらをテストサーバーに展開して、クライアントから呼び出すことができます。両側C＃/VS2010。サービスはIIS6でホストされています。現時点では、より新しいオプションはありません。

つまり、HTTPはIIS 6でしか使用できないことを読みました。これにより、バインディングとしてbasicHttpBindingまたはwsHttpBindingに制限されると思います。

また、wsHttpBindingを使用してネットワーク経由で送信されるXMLは暗号化されていますが、basicHttpBindingは暗号化されていないことも読みました。

したがって、ある種の認証が必要であり、ユーザー名/パスワードが着信メッセージとともに渡されると思われるため、wsHttpBindingを使用したいようです。

最初の質問は、wsHttpBindingを使用する場合、クライアントはhttpsを使用して呼び出す必要がありますか？そして、サーバー上の証明書などについて心配する必要がありますか？

2番目の質問は-私が利用できるセキュリティオプションは何ですか？発信者はサーバー上のWindowsユーザーである必要がありますか、それとも自分のユーザー名/パスワードを作成して、サービスとサービスのその部分に検証を行わせ、Windowsユーザーとは関係がないようにすることはできますか？Windowsユーザーと一緒に行く必要がある場合、サーバーに1つのユーザーアカウントを設定し、すべての発信者にそれを使用させるのが一般的だと思いますか？

基本的な考え方は、このサービスを選択した発信者に公開する必要があるということですが、誰もがサービスを見つけて呼び出すことができるようにしたくはありません。誰がサービスを呼び出すかをなんとかして制御する必要があります。ユーザー名/パスワードはこれを行うための標準的な方法ですか？たとえば、すべての呼び出し元が渡さなければならないGUIDを定義できますか？

PHP クライアントと AKAIK で WCF Web サービス (1.2) を使用する必要があります。php は wsHttpBinding メソッドにネイティブに準拠していません (本当ですか?)。試してみたところ、WSDL ファイルを使用してエラーが発生しました。

そしてそれなしで：

Nusoap は SOAP 1.2 をサポートしていないため、役に立ちません。WSO2 (複雑すぎて統合できない) 以外に使用できる別のソリューションはありますか?

アドバイスをありがとう

編集ここにWSDLファイルがあります：

WCFHttpバインディングを選択するのに役立つ次の基準があります。私のサービスは次のことを行う必要があります。

1. イントラネットサポートのなりすまし/委任で展開される
2. 未知のテクノロジーを使用してクライアントと相互運用可能であること
3. クライアントとサーバー間のトランザクションフローをサポートする
4. 可能であれば証明書を使用しない（「トランスポート」セキュリティモードを破棄する）

basicHttpBindingとwsHttpBindingのどちらかを決定する必要があります。

ここに、3つのポイントに関するいくつかのメモと質問があります。

1. 「メッセージ」セキュリティモードと「Windows」clientCredentialTypeを使用したwsHttpBindingを使用すると、委任を実行できると思います。
2. ポイント1で選択したセキュリティ構成は、委任を実装するために相互運用性をサポートするのが複雑になるようですが、私は正しいですか？WS- *標準（wsHttpBinding）は間違いなく相互運用可能ですが、「メッセージ」セキュリティと「Windows」クレデンシャルと組み合わせると、WS- *互換クライアントでサービスを呼び出すことができますか？
3. wsHttpBindingは、トランザクションフローをサポートするためにここに行く方法のようだと思いますか？
4. 私たちの状況では、証明書なしで「メッセージ」セキュリティを使用する方が簡単に思えますか？

前もって感謝します

当社は、クライアントに音楽サービスを貸与しています。この製品は、自動化されたmp3プレーヤーと、マシンにダウンロードされたコスチューム音楽ライブラリ（mp3曲）の毎日の更新/更新で構成されています。これまでのところ、GBridgeを使用してサーバーとクライアントのフォルダーを同期することにより、mp3の更新に醜いソリューションを使用しています。これは明らかに不利です。クライアントに音楽ライブラリ全体（現在は25.000曲）をダウンロードするように強制しますが、ほとんどのクライアントはすべての音楽カテゴリ（ポップ、ロックなど）の曲を再生することはありません。最も重要なのは、サブスクリプションパケット（音楽ライブラリ全体）を1つしか提供できないのに対し、競合他社はカテゴリごとに低価格でパケットを提供していることです。これらの理由から、WCFに目を向けることにしました。

このサービスは、PerCallインスタンス化モードを使用し、従来の要求/応答パターンを使用してwinformクライアントアプリケーションから呼び出される2つの操作を実装します。

最初の操作では、クライアントがダウンロードを許可されているカテゴリをデータベースから取得し（要求）、これらのカテゴリのリストをクライアントに送り返します（応答）。

2番目の操作はダウンロードに使用されます。クライアントは最初にサーバーのデータベースのxmlバージョンをダウンロードします。同様のxmlがクライアント側にあります。クライアントアプリは、最初の操作から返された各カテゴリのどの曲が、サーバーのxmlファイルと比較して独自のxmlに欠落しているかを確認します。欠落しているファイル（xmlの要素）がある場合は、一度に1つのファイルをダウンロードします。ダウンロードするたびに、クライアントは自分のxmlを更新し、すべてのファイル（要素）が2つのxmlで一致するまで、同じ比較を再度実行します。

簡単に言うと、サービスのインスタンス化モードはスループットの理由とメモリ消費量を低く抑えるためにPerCallであり、両方の操作で要求と応答のパターンが使用されていることを考えると、応答ごとに確認メッセージがクライアントに返送されます。サービスであるため、接続で問題が発生した場合、またはクライアントがサービスに到達できない場合は、クライアントでCommunicationObjectFaultedExceptionをキャッチし、プロキシを再構築して再試行します。サービスの実装で信頼できるセッションが必要だと思いますか？今説明した操作で信頼できるセッションがない場合、どのような問題が発生する可能性がありますか？

asp.net webforms イントラネット アプリケーションで netTcpBinding を使用します。

クライアント マシンでは、wcf を介してデータを取得する activeX (winforms) が実行されています。

ActiveX コンテナーは、asp.net アプリケーション内にあります。

netTcpBinding よりも wsHttpBinding を使用することには、どのような利点がありますか?

構成が正しく機能するようになりました。実際のファイル構造とVisualStudioのプロジェクト構造の間に不一致がありました。愚かな愚かな間違い:)

ただし、basicHttpBindingからWsHttpBindingへの移行の問題があります。これはwebconfigです。ご覧のとおり、最初のエンドポイントをwsHttpBindingタイプに変更しました。

これをローカルホストでローカルに実行しようとすると、次のエラーメッセージが表示されます。

IISが複数のベースアドレスを解決することについて話しているアーティルを見つけましたが、これはローカルであるため、なぜ機能しないのかわかりません。

ここに欠けているものはありますか？basicHttpBindingsのみを使用している限り、構成ファイルは正常に機能します。

どんな助けでも大歓迎です、tyvm！