|
Subject:
|
PhileIdentity - System.InvalidCastException
|
|
Posted By:
|
terencetham
|
Post Date:
|
6/26/2004 2:46:59 PM
|
Does anyone have a solution to the casting issue in the Site Header with the following line of code:
PhileIdentity id = (PhileIdentity)Context.User.Identity;
This line of code produces the following error:
System.InvalidCastException: Specified cast is not valid.
I have no really no idea how to solve it....can anyone offer help on this please?
Thanks in advance
Terence Tham
|
|
Reply By:
|
bmains
|
Reply Date:
|
6/26/2004 3:37:22 PM
|
Hey,
Are you setting the PhilePrincipal object to the Context.User before accessing the PhileIdentity object?
Brian
|
|
Reply By:
|
terencetham
|
Reply Date:
|
6/26/2004 4:35:13 PM
|
Thanks Brian, i managed to solve the problem
For the guys out there with similar problem...the default.aspx have to inherit the PhilePage class, then the cast exeception problem will be solved...
Thanks
Terence Tham
|
|
Reply By:
|
englere
|
Reply Date:
|
6/28/2004 4:39:50 AM
|
This is a common problem, so I thought I'd elaborate on this some more to help other people.
First, each page needs to descend from the base page. This ensures that the Identity and Principle context will be set right.
Wrox.ThePhile.Web.PhilePage.
Secondly, the normally collapsed region "Web Form Designer generated code" that you see at the end of your code-behind file needs to have an override of the base page's OnInit method, and it has to call the base page's OnInit BEFORE it executes InitializeComponent.
In C# (comments removed to save space):
#region Web Form Designer generated code
override protected void OnInit(EventArgs e)
{
base.OnInit(e); // MUST COME FIRST!!!
InitializeComponent();
}
private void InitializeComponent()
{
this.Load += new System.EventHandler(this.Page_Load);
}
#endregion
And the MOST important item that most people forget to do (including the authors of the book): EVERY single page that requires special security permissions MUST have these lines of code right at the beginning of Page_Load:
private void Page_Load(object sender, EventArgs e)
{
if (!Context.User.Identity.IsAuthenticated ||
!((PhilePrincipal)Context.User).HasPermission(
(int)FilesPermissions.AdministerFiles))
{
// if not, redirect to the Login page
Response.Redirect("/Modules/Users/Login.aspx?ShowError=true",
true);
}
This value above: "FilesPermissions.AdministerFiles" is defined in enums.cs. This is the new value I set up to give Forms security to the FileManager. Many newbies to ThePhile don't understand the very big security risk when deploying ThePhile to a commercially-hosted website. The FileManager was designed to use Windows authorization, which is NOT available in a hosted site. If you fail to convert all of the pages of FileManager to use Forms authorization, then you aren't just giving your car away to an intruder, but you're also giving him the keys!
For other modules that use other security enumerations, you just need to replace "FilesPermissions.AdministerFiles" with the specific permission you want to test for.
Anyone who doesn't understand these items needs to study this subject more before deploying a web site. Even if you can use Windows authorization on the FileManager (which I recommend against), you still need to use this Forms authorization on EVERY sensitive page that can be accessed from the web - not just the main admin page of each module.
Windows authorization can only be used to control access to computers in your local network domain. Windows auth can NOT be used accross the Internet - you have to use Forms authorization in this case.
I hate to keep talking about FileManager here, but it's very important that people get this. The authors of ThePhile set up Windows authorization on the FileManager using NTFS security (p. 129 in the C# book). This is NOT done in code! If you deploy the code, but you forget to set the NTFS security restrictions (or if you can't set this because it's a hosted site), then there will be NO access control on the most critical module of the whole application. This is why I strongly advise people to use Forms authorization on this module - after all, Forms auth is being used on all the other admin modules!!!
Eric
|
|
Reply By:
|
JRMotz
|
Reply Date:
|
4/21/2006 12:17:05 AM
|
I don't understand y mine is working. I'm getting the same errors but i've checked all suggestions that were given and my code is correct so far. Anything else ...
|
|
Reply By:
|
bmorrison
|
Reply Date:
|
9/25/2006 10:23:53 AM
|
I am trying to use this model in a Visual Studio 2005 project. The problem I am running into is I am getting an invalidcastexception when trying to cast the principal to my custom principal. I got this error in the past with VS 2003 and I fixed it using englere suggestion with moving the OnInit call before InitializeComponent. I don't know what I should do in VS 2005 because it doesn't use the InitializeComponent method anymore. Any suggestions??
|
|
Reply By:
|
bmorrison
|
Reply Date:
|
9/25/2006 2:27:19 PM
|
Ok, I have solved my problem. First, the AutoEventWireup attribute on aspx pages is set to true by default in VS 2005 and it should be set to false. This was causing the Page_Load of the page to get called before the Page_Load of the base page.
|
