SoapClientで、Windows認証を行う場合
1.IISのアプリケーション設定で、Windows認証に設定していること
2.サーバ側のWeb.configで、Windows認証を設定していること
3.Client側のWebサービス設定値で、Windows認証にしていること
app.configの設定で以下を追加
<basichttpBiding>
<Binding>
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows" proxyCredentialType="Windows" realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
</Biding>
Client側の設定が良く分からなかったので、認証エラー401が発生した。
ソースはこちら
namespace PCS_SendMail
{
class Program
{
static void Main(string[] args) {
PCS_ServiceReference.SendMailWebServiceSoapClient cl = new PCS_ServiceReference.SendMailWebServiceSoapClient();
cl.ClientCredentials.Windows.ClientCredential.Domain = "Hoge";
cl.ClientCredentials.Windows.ClientCredential.UserName = "Mail";
cl.ClientCredentials.Windows.ClientCredential.Password = "password";
cl.Open();
cl.SendMail(args[0], args[1], args[2]);
cl.Close();
}
}
}
2012年3月27日火曜日
2012年3月22日木曜日
Telerik Reportのフォントを変更
Telerik Reportのフォントを変更する方法
レポートのコード部分で、Class生成部分で
public rptExpenseReport(string iEntityCode) {
//
// Required for telerik Reporting designer support
//
InitializeComponent();
//
// TODO: Add any constructor code after InitializeComponent call
//
if (iEntityCode == "74") {
this.txtAccountCode.Style.Font.Name = "Dotum";
this.txtAccountCode.Style.Font.Bold = true;
this.txtPurposeCompany.Style.Font.Name = "Dotum";
this.txtPurposeCompany.Style.Font.Bold = true;
this.txtDescription.Style.Font.Name = "Dotum";
this.txtDescription.Style.Font.Bold = true;
}
}
レポートのコード部分で、Class生成部分で
public rptExpenseReport(string iEntityCode) {
//
// Required for telerik Reporting designer support
//
InitializeComponent();
//
// TODO: Add any constructor code after InitializeComponent call
//
if (iEntityCode == "74") {
this.txtAccountCode.Style.Font.Name = "Dotum";
this.txtAccountCode.Style.Font.Bold = true;
this.txtPurposeCompany.Style.Font.Name = "Dotum";
this.txtPurposeCompany.Style.Font.Bold = true;
this.txtDescription.Style.Font.Name = "Dotum";
this.txtDescription.Style.Font.Bold = true;
}
}
2012年3月13日火曜日
LINQでGroup byを行う
var vAssyRecs =
from rc in db.vIF_EPLAN
orderby rc.AssyNo
where rc.TopParent == Request.QueryString["ml"].ToString()
&& rc.AssyNo.Trim() != ""
group rc by rc.AssyNo into g
select new
{
g.Key,
Description = g.Max(p => p.ParentDescription)
};
AssyNoをキーとして、Group byを行う
この時、名称をMax関数で取得している。
from rc in db.vIF_EPLAN
orderby rc.AssyNo
where rc.TopParent == Request.QueryString["ml"].ToString()
&& rc.AssyNo.Trim() != ""
group rc by rc.AssyNo into g
select new
{
g.Key,
Description = g.Max(p => p.ParentDescription)
};
AssyNoをキーとして、Group byを行う
この時、名称をMax関数で取得している。
2012年3月12日月曜日
UniPaas ENterPrice Serverとリッチを同一サーバで動作
UniPaas ENterPrice Serverとリッチを同一サーバで動作させる場合
今回は、EnterPriceServer側に、MAGIC Brokerをインストールした。
その次にリッチをインストールする場合、ブローカーはインストールされない(しない)
また、EnterPriceServerのMGRB.iniに、アプリケーションを登録するが
実行フォルダは、EnterPriceServerのフォルダを指定する。
※何故か、リッチアプリケーションを、リッチサーバのフォルダを指定したら
リッチアプリケーションが起動しない。
環境 UniPaas 1.9G2
今回は、EnterPriceServer側に、MAGIC Brokerをインストールした。
その次にリッチをインストールする場合、ブローカーはインストールされない(しない)
また、EnterPriceServerのMGRB.iniに、アプリケーションを登録するが
実行フォルダは、EnterPriceServerのフォルダを指定する。
※何故か、リッチアプリケーションを、リッチサーバのフォルダを指定したら
リッチアプリケーションが起動しない。
環境 UniPaas 1.9G2
2012年3月9日金曜日
Vista (IIS 7) へのファイルアップロード制限
Vista (IIS 7) へのファイルアップロード制限
2007/8/26 日曜日 コメントなし
Vista上でASP.NETをベースとしたウェブアプリケーションを作っていて、そのなかでクライアントからファイルをアップロードする処理がある。転送ファイルは30MBを超えるものがあって、Vista (IIS 7) では31MBくらいのファイルはクライアントから問題なくアップロードできるのに、32MBくらいから失敗する。ちなみに、XPでは同じコード、同じ転送ファイルなのにすんなりとアップロードは成功する。
いろいろと調べた結果、Vista (IIS 7) にはやはりアップロードできるファイルの制限がかけられていた。
と、その前に、ASP.NETではXPでもそうだけど、アップロードできるファイルサイズは4MBに制限されている。その制限を変更するには、Web.configに
を追加する。デフォルトでは 4096 (4MB) が設定されているはず。上の例では 100MB に変更している。
さて、Vistaではさらに制限があって、それを変更するには、%windir%\System32\inetsrv\config\applicationHost.configを編集する必要がある。が、Vistaではシステムファイルの編集にアクセス権が設定されていて、エディタで開こうとしても拒否されてしまう。そこで、エディタ(メモ帳でもいい)を管理者として実行して(右クリックして「管理者として実行」を選ぶ)、エディタからファイルを開けば編集できる。ここでは以下の設定を変更する。
Deny → Allow にする。そして、Web.configに以下の設定を追加する。
これでようやく32MBを超えるファイルもアップロードできるようになった。
2007/8/26 日曜日 コメントなし
Vista上でASP.NETをベースとしたウェブアプリケーションを作っていて、そのなかでクライアントからファイルをアップロードする処理がある。転送ファイルは30MBを超えるものがあって、Vista (IIS 7) では31MBくらいのファイルはクライアントから問題なくアップロードできるのに、32MBくらいから失敗する。ちなみに、XPでは同じコード、同じ転送ファイルなのにすんなりとアップロードは成功する。
いろいろと調べた結果、Vista (IIS 7) にはやはりアップロードできるファイルの制限がかけられていた。
と、その前に、ASP.NETではXPでもそうだけど、アップロードできるファイルサイズは4MBに制限されている。その制限を変更するには、Web.configに
さて、Vistaではさらに制限があって、それを変更するには、%windir%\System32\inetsrv\config\applicationHost.configを編集する必要がある。が、Vistaではシステムファイルの編集にアクセス権が設定されていて、エディタで開こうとしても拒否されてしまう。そこで、エディタ(メモ帳でもいい)を管理者として実行して(右クリックして「管理者として実行」を選ぶ)、エディタからファイルを開けば編集できる。ここでは以下の設定を変更する。
Deny → Allow にする。そして、Web.configに以下の設定を追加する。
これでようやく32MBを超えるファイルもアップロードできるようになった。
2012年3月7日水曜日
2012年3月6日火曜日
SVG-edit
SVG-edit
ブラウザ上で動くSVGグラフィックエディタのオープンソースが超凄いです。
次のようなインタフェースで、Chromeだとサクサク動くSVGエディタがGoogle codeにてオープンソースでダウンロード可能です。
SVGでお手軽にお絵かきしたい場合や、SVGなお絵かきサイトなんかを作るのにも活用できそう
元ネタ
http://phpspot.org/blog/archives/2010/10/svg_1.html
ブラウザ上で動くSVGグラフィックエディタのオープンソースが超凄いです。
次のようなインタフェースで、Chromeだとサクサク動くSVGエディタがGoogle codeにてオープンソースでダウンロード可能です。
SVGでお手軽にお絵かきしたい場合や、SVGなお絵かきサイトなんかを作るのにも活用できそう
元ネタ
http://phpspot.org/blog/archives/2010/10/svg_1.html
2012年3月5日月曜日
UniPaas Richアプリを複数動作させる方法
UniPaas Richアプリを複数動作させる方法
Magic.iniの
MaxConcurrentUsers = 0
上記値を変更する
MaxConcurrentRequests = 0
この値は、UniPaas ENterPriceServerの場合に使用する
Magic.iniの
MaxConcurrentUsers = 0
上記値を変更する
MaxConcurrentRequests = 0
この値は、UniPaas ENterPriceServerの場合に使用する
2012年3月3日土曜日
[HttpException (0x80004005): URL にエンコードされたフォーム データが有効ではありません。]
オブジェクトの現在の状態に問題があるため、操作は有効ではありません。
説明: 現在の Web 要求を実行中に、ハンドルされていない例外が発生しました。エラーに関する詳細および例外の発生場所については、スタック トレースを参照してください。
例外の詳細: System.InvalidOperationException: オブジェクトの現在の状態に問題があるため、操作は有効ではありません。
ソース エラー:
現在の Web 要求の実行中にハンドルされていない例外が生成されました。障害の原因および発生場所に関する情報については、下の例外スタック トレースを使って確認できます。
スタック トレース:
[InvalidOperationException: オブジェクトの現在の状態に問題があるため、操作は有効ではありません。]
System.Web.HttpValueCollection.ThrowIfMaxHttpCollectionKeysExceeded() +2420362
System.Web.HttpValueCollection.FillFromEncodedBytes(Byte[] bytes, Encoding encoding) +58
System.Web.HttpRequest.FillInFormCollection() +159
[HttpException (0x80004005): URL にエンコードされたフォーム データが有効ではありません。]
System.Web.HttpRequest.FillInFormCollection() +217
System.Web.HttpRequest.get_Form() +104
System.Web.HttpRequest.get_Item(String key) +40
Telerik.Web.UI.RadCompression.IsAjaxRequest() +50
Telerik.Web.UI.RadCompression.Compress(HttpApplication application) +373
Telerik.Web.UI.RadCompression.PreRequestHandlerExecute(Object sender, EventArgs e) +43
System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +148
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +75
原因としては、「MS11-100」によって、.NET Framework のいくつかの問題が解決されています。
これにより導入されたセキュリティパッチの中に、「一時的にハッシュテーブルの衝突に友なる潜在的な DoS 攻撃を軽減する」を修正するために、POSTデータの多くを含むページの PostBack に問題が生じます。
幾つかの情報から、PostBack 項目が 500 に到達すると上のようなエラーが発生するようです。
回避策は、画面上のコントロールの数を少なくするのがいいのでしょうが、実際に動いているサービスではそれは難しい事になってくる。
私も最初この問題が発生したときに、PostBack に必要なデータが多すぎるために発生しているのではないかと推測はできた。
しかし、なかなか有効な情報に辿りつけなくて...さまよっていた。考える事、1時間そうかぁ validateRequest や PostBack 時の検証のチェックをしなければ....っと思って
Page で設定を行なってみたが、やはり解決しない。
結論を書くと、正確な対応としては、上記にある通り、一画面に出るコントロールを減らすのがセキュリティ面から考えても正しいのだろう。しかし、そうも行っていられない。
web.config に、
<appsettings>
<add key="aspnet:MaxHttpCollectionKeys" value="5001" />
</appSettings>
と記述するだけで、少なくても上限だと思われる10倍の5001個のコントロールになる。
後は、環境で増やしていけばいい。
根本解決ではないけど、回避策にはなる。
説明: 現在の Web 要求を実行中に、ハンドルされていない例外が発生しました。エラーに関する詳細および例外の発生場所については、スタック トレースを参照してください。
例外の詳細: System.InvalidOperationException: オブジェクトの現在の状態に問題があるため、操作は有効ではありません。
ソース エラー:
現在の Web 要求の実行中にハンドルされていない例外が生成されました。障害の原因および発生場所に関する情報については、下の例外スタック トレースを使って確認できます。
スタック トレース:
[InvalidOperationException: オブジェクトの現在の状態に問題があるため、操作は有効ではありません。]
System.Web.HttpValueCollection.ThrowIfMaxHttpCollectionKeysExceeded() +2420362
System.Web.HttpValueCollection.FillFromEncodedBytes(Byte[] bytes, Encoding encoding) +58
System.Web.HttpRequest.FillInFormCollection() +159
[HttpException (0x80004005): URL にエンコードされたフォーム データが有効ではありません。]
System.Web.HttpRequest.FillInFormCollection() +217
System.Web.HttpRequest.get_Form() +104
System.Web.HttpRequest.get_Item(String key) +40
Telerik.Web.UI.RadCompression.IsAjaxRequest() +50
Telerik.Web.UI.RadCompression.Compress(HttpApplication application) +373
Telerik.Web.UI.RadCompression.PreRequestHandlerExecute(Object sender, EventArgs e) +43
System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +148
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +75
原因としては、「MS11-100」によって、.NET Framework のいくつかの問題が解決されています。
これにより導入されたセキュリティパッチの中に、「一時的にハッシュテーブルの衝突に友なる潜在的な DoS 攻撃を軽減する」を修正するために、POSTデータの多くを含むページの PostBack に問題が生じます。
幾つかの情報から、PostBack 項目が 500 に到達すると上のようなエラーが発生するようです。
回避策は、画面上のコントロールの数を少なくするのがいいのでしょうが、実際に動いているサービスではそれは難しい事になってくる。
私も最初この問題が発生したときに、PostBack に必要なデータが多すぎるために発生しているのではないかと推測はできた。
しかし、なかなか有効な情報に辿りつけなくて...さまよっていた。考える事、1時間そうかぁ validateRequest や PostBack 時の検証のチェックをしなければ....っと思って
Page で設定を行なってみたが、やはり解決しない。
結論を書くと、正確な対応としては、上記にある通り、一画面に出るコントロールを減らすのがセキュリティ面から考えても正しいのだろう。しかし、そうも行っていられない。
web.config に、
<appsettings>
<add key="aspnet:MaxHttpCollectionKeys" value="5001" />
</appSettings>
と記述するだけで、少なくても上限だと思われる10倍の5001個のコントロールになる。
後は、環境で増やしていけばいい。
根本解決ではないけど、回避策にはなる。
2012年3月2日金曜日
SVGをiFrameで表示
IE6とIE8で、SVGを表示すると、画面サイズが大きい場合、画面スクロールしてくれない。
(IE9では、正常に画面スクロールしてくれる。)
SVGをXAMLに変換して表示しようとすると、XAML変換が、WPF対応になってしまう。
SilverLightでは、ちと面倒な変換が必要になった。
SilverLightで強引に、WebBrowserで表示させようかと思ったけど
表示権限が必要でうまく行かない。
htmlで、iFrameを使用したら、フレーム枠を設定出来るからいけるかもと思い、実験すると
思った通りにIE6でも、画面スクロールしてくれた。
(IE9では、正常に画面スクロールしてくれる。)
SVGをXAMLに変換して表示しようとすると、XAML変換が、WPF対応になってしまう。
SilverLightでは、ちと面倒な変換が必要になった。
SilverLightで強引に、WebBrowserで表示させようかと思ったけど
表示権限が必要でうまく行かない。
htmlで、iFrameを使用したら、フレーム枠を設定出来るからいけるかもと思い、実験すると
思った通りにIE6でも、画面スクロールしてくれた。
Visio to XAML
Visioで書いたフローをWebブラウザーで表示したいと考えていた。
VisioからSVG形式で出力できるので、コレでOKからと思ったら
IE6のAdobe SVG Viwerで画面スクロールしない。
仕方ないので、VisioからXAML形式に直接出力するToolがあった。
http://visioautomation.codeplex.com/
CodePlexで公開されていた。
VisioからSVG形式で出力できるので、コレでOKからと思ったら
IE6のAdobe SVG Viwerで画面スクロールしない。
仕方ないので、VisioからXAML形式に直接出力するToolがあった。
http://visioautomation.codeplex.com/
CodePlexで公開されていた。
登録:
投稿 (Atom)