Application column in SqlLogger's table is not the same

[GoogleCodeExporter]

In the current version of ELMAH, the application column is set 
to '/LM/W3SVC/170/ROOT' by the SQLLogger.

In this beta version, it is set to '/'.

Original issue reported on code.google.com by wayne.br...@gmail.com on 16 Jul 2007 at 10:58

[GoogleCodeExporter]

Could you expand on the current version? Do you mean GDN-ELMAH 1.0.5527? If so, 
this 
is to be expected. To allow ELMAH to run under Medium trust, a different method 
of 
auto-discovering a sensible application name was needed. This could suprise 
folks 
when moving from GDN-ELMAH to the new beta version because the log would appear 
empty right after the upgrade when it real fact it would be just getting 
filtered 
due to the applicaton name not matching. A quick fix would be to UPDATE the 
column 
holding the application name, but a more involved one will need to also patch 
the 
detailed error information XML. Perhaps a script would help here?

Original comment by azizatif on 16 Jul 2007 at 11:06

[GoogleCodeExporter]

Yes, I mean current released version, which is 1.0.5527.

That is fine, I figured it was a medium trust issue.  Since it is, we need a 
way to 
specify the 'application' column from code/config.

I am not interested in the updating the column name, etc - just wanted to 
report 
this issue - so that I could set the application name that goes into that 
column.

Original comment by wayne.br...@gmail.com on 17 Jul 2007 at 2:59

[GoogleCodeExporter]

The problem with making the application name configurable is that it can make 
it 
very easy for someone to expose other logs or cause conflicts in a hosted 
environment. For example, if many applications are sharing the same ELMAH 
database 
then filtering is applied by application name to isolate the errors of one 
application from another. If someone could guess another application's name or 
make 
a configuration error then it could create a fragile situation. It's not the 
tightest form of security but hopefully it's an acceptable measure of default 
safety.

A workaround to make your case work would be to add a class to your App_Code 
that 
inherits from SqlErrorLog and overrides ApplicationName property to 
return "/LM/W3SVC/170/ROOT" (or even make it configurable as you see fit). In 
the 
web.config file, you'll then need to specify the newly subclassed error log 
implementation instead of the SqlErrorLog coming from ELMAH.

Original comment by azizatif on 17 Jul 2007 at 10:07

• Changed title: Application column in SqlLogger's table is not the same

[GoogleCodeExporter]

Well, as it is now - every application will look like the root '/', so they 
will all 
be able to see each others logs anyway!!

How do you propose the application name be set then?

Original comment by wayne.br...@gmail.com on 18 Jul 2007 at 1:46

[GoogleCodeExporter]

That's a good catch and you're absolutely right. All applications installed at 
the 
root on a single machine sharing a single SQL error log will have their records 
mixed up. The case of that works right now though is where applications are 
running 
off virtual directories from the root (so /app1, /app2, ..., /appN). This is 
not the 
general shared hosting case per se, but it works for operations environments 
within 
companies where a single machine may be host to several application installed 
under 
the root. The old scheme based on meta-directory path worked really nicely but 
is 
unusable under medium trust. Based on some experimentation, the only property 
found 
to be accessible under medium trust that could be used (reasonably) to compute 
the 
application name automatically was HttpRuntime.AppDomainAppVirtualPath. It's 
not the 
right solution for the final release, but it's the one that was used get a BETA 
out. 
Do you have any ideas or suggestions for handling of the application name based 
on 
the input so far?

Original comment by azizatif on 19 Jul 2007 at 8:43

[GoogleCodeExporter]

Actually I think this is exactly what happens at shared hosting.  Each person 
who 
has their OWN DOMAIN, which would be most people - have a site at the root of 
that 
domain.  If you are allowed to host mulitple domains with this hoster, then 
each of 
them (with their own domain name) is a root....

When you use the Profile feature of ASP.NET, it works under medium trust - it 
uses 
the 'application name' in the aspnet_Applications table.  What about that?

Original comment by wayne.br...@gmail.com on 20 Jul 2007 at 2:23

[GoogleCodeExporter]

Yep and the problem would exist for subdomains as well. 

The providers in ASP.NET allow you to set the application name directly via 
configuration or property setter but my guess is that they're not expecting 
medium 
trust applications to be sharing a single database. The expectation may there 
be 
that everyone will have their own private copy of the backing tables in their 
own 
databases (which is also going to be the most common case by far for ELMAH). I 
doubted if any hoster is going to offer ELMAH to hosted sites with a shared 
database 
so perhaps all this concern is just paranoia :) but it is a nice goal to try 
and 
achieve nonetheless. I've seen many cases where developers/operations would 
frantically install ELMAH to deparately get error diagnostics from applications 
failing in production. To not disturb the databases of each application, the 
person 
adding ELMAH will usually create a shared database.

I still don't have a good idea here as yet but one possible workaround is to 
leverage ServerVariables. The APPL_MD_PATH key in there basically gives back 
the old 
GDN-ELMAH behavior. The only problem here is that ServerVariables are only 
available 
at the time of an HTTP transaction so you'd have always have an HttpContext 
hanging 
around to get at the ErrorLog and that's adding an unnecessary dependency. 
Ideally, 
ErrorLog wouldn't even have a dependency on HttpRuntime as it does now.

Original comment by azizatif on 20 Jul 2007 at 5:10

[GoogleCodeExporter]

The providers allow you to set the application name directly, and that is 
BECAUSE 
they are expecting medium trust applications to be sharing a single database!!! 

That application name causes everything to be broken out by application name - 
so as 
long as you use different application names, you can share a database.   It is 
not 
meant to be a 'hoster shared', but rather shared among YOUR OWN SITES, where 
you can 
specifiy different names for each site.

I personally dont see what the problem is in providing a configuration or 
property 
setter for ELMAH, that defaults to the setting in the provider - if a provider 
is in 
use....

Original comment by wayne.br...@gmail.com on 23 Jul 2007 at 1:09

[GoogleCodeExporter]

Original comment by azizatif on 10 Oct 2007 at 8:45

• Changed state: Accepted
• Added labels: Component-Logic, Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Original comment by azizatif on 10 Oct 2007 at 11:40

• Changed state: Started

[GoogleCodeExporter]

Fixed in r184.

Original comment by azizatif on 12 Oct 2007 at 4:52

• Changed state: Fixed