Asked  10 Months ago    Answers:  5   Viewed   14 times

I have in my web application an ADO.NET Entity-Framework *.edmx file.

When I browse in the browser (when the application is running) to an edmx file, it doesn't show the error page like when browsing to a *.cs or vb file, it opens the edmx and shows my model scheme to all the users!!!

How can I avoid that.



You can do this two ways; firstly in the web.config or secondly in IIS

        <add verb="*" path="*.edmx" type="System.Web.HttpForbiddenHandler" />

Here's a link to a microsoft support page that details how to do it in the web config and IIS.

Tuesday, August 3, 2021

A lot of the answers I found were almost what I needed but not quite right. I wound up setting up membership and implementing a custom attribute to pull an authorization header and process login as the request came in. All of the magic happens in BeforeCall and ParseAuthorizationHeader below:

public class UsernamePasswordAuthentication : Attribute, IOperationBehavior, IParameterInspector
    public void ApplyDispatchBehavior(OperationDescription operationDescription,
        DispatchOperation dispatchOperation)

    public void AfterCall(string operationName, object[] outputs,
                          object returnValue, object correlationState)

    public object BeforeCall(string operationName, object[] inputs)
        var usernamePasswordString = parseAuthorizationHeader(WebOperationContext.Current.IncomingRequest);
        if (usernamePasswordString != null)
            string[] usernamePasswordArray = usernamePasswordString.Split(new char[] { ':' });
            string username = usernamePasswordArray[0];
            string password = usernamePasswordArray[1];
            if ((username != null) && (password != null) && (Membership.ValidateUser(username, password)))
                Thread.CurrentPrincipal = new GenericPrincipal(new GenericIdentity(username), new string[0]);
                return null;

        // if we made it here the user is not authorized
        WebOperationContext.Current.OutgoingResponse.StatusCode =
        throw new WebFaultException<string>("Unauthorized", HttpStatusCode.Unauthorized);            

    private string parseAuthorizationHeader(IncomingWebRequestContext request)
        string rtnString = null;
        string authHeader = request.Headers["Authorization"];
        if (authHeader != null)
            var authStr = authHeader.Trim();
            if (authStr.IndexOf("Basic", 0) == 0)
                string encodedCredentials = authStr.Substring(6);
                byte[] decodedBytes = Convert.FromBase64String(encodedCredentials);
                rtnString = new ASCIIEncoding().GetString(decodedBytes);
        return rtnString;

    public void AddBindingParameters(OperationDescription operationDescription, System.ServiceModel.Channels.BindingParameterCollection bindingParameters)

    public void ApplyClientBehavior(OperationDescription operationDescription, ClientOperation clientOperation)

    public void Validate(OperationDescription operationDescription)


From there I just need to add my new attribute to the service contract entries. Any request to that method will require a valid authorization header or a Not Authorized response will be sent back with doing any further processing.

interface ILocationService
    string GetLocation(string id);

    [UsernamePasswordAuthentication]  // this attribute will force authentication
    string GetHiddenLocation(string id);
Sunday, August 1, 2021

Even if there was, it wouldn't do you much good since you would still have to catch the exception in order to handle the race condition where the file became unavailable in between your initial check and your actual attempt to open/access it.

I can't think of any compelling advantage to a preliminary defensive check. It just results in unnecessary code duplication.

If there were such a IsFileAccessible function, it would probably be implemented as a giant try/catch block that attempted to open the file, caught failures, and returned the result.

Thursday, August 5, 2021

Follow this: Source - 2

“Setting Directory Permissions with Windows Hosting Accounts”

You should ask your hosting provider for access permissions if it doesn't solve your problem.

Ref: Removing Web Access to Directories on a Windows Hosting Account

Removing the "Anonymous Access" IIS Setting for that directory. The result of removing this permission is that you can only access that directory from with your hosting account or via FTP. You will not be able to access the directory through any Web browser, regardless of whether you are knowledgeable of the hosting account user name and password.

Monday, August 16, 2021

@Michael - sqlbot is right.

It seems what you are doing is restrict access to the S3 bucket where you store that static web content to requests coming from a particular AWS VPC, using a VPC endpoint.

VPC endpoints establish associations between AWS services, to allow requests coming from INSIDE the VPC.

You can't get what you want with VPC and S3 ACL configuration, but you can get it with ACL and some VPN configuration.

Let's assume connecting to your company's VPN doesn't mean that all the traffic, including Internet traffic between the VPN clients and AWS S3 will be routed through that VPN connection, because that's how sane VPN configuration usually works. If that's not the case, ommit the following step:

  1. Add a static route to your S3 bucket to your VPN server configuration, so every client tries to reach the bucket through the VPN instead of trying to establish a direct internet connection with it. For example, on OpenVPN, edit server.conf, adding the following line:

    push "route yourS3bucketPublicIP"

After that you will see that when a client connects to the VPN it gets an extra entry added to its routing table, corresponding to the static route that tells it to reach the bucket trough the VPN.

  1. Use S3 bucket ACLs "IpAddress" field to set the configuration you want. It should look something like this:


  "Version": "2012-10-17",
  "Id": "S3PolicyId1",
  "Statement": [
      "Sid": "IPAllow",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::examplebucket/*",
      "Condition": {
         "IpAddress": {"aws:SourceIp": ""},
         "NotIpAddress": {"aws:SourceIp": ""} 

You use IpAddress field to allow an IP or range of IPs using CIDR notation, and NotIpAddress field the same way for restricting an IP or range of IPs (you can ommit that one). That IP (or range of IPs) specified on IpAddress should be the public address(es) of the gateway interface(s) that route(s) your company's VPN Internet traffic (the IP address(es) S3 sees when somebody from your VPN tries to connect to it).

More info:

Tuesday, September 14, 2021
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :