I had a Glimpse install working fine, and then updated from 1.2 to 1.3, and now when I go to glimpse.axd, I see "Resource with name 'glimpse_config' could not be found."
This is an ASP.NET 4.5 site (DotNetNuke 7.0.5), with Glimpse.Core 1.3 and Glimpse.AspNet 1.2.1 (previously, it has Glimpse.Core 1.2, Glimpse.AspNet 1.2, and Glimpse.Ado 1.2), running on IIS 8.
Any ideas about what I should be investigating to see where the error is coming from?
I think I figured it out. I had a custom security policy that required me to be logged in. When the security policy turned Glimpse off, it looks like that's the response that I get.
Related
Problem statement:
Application built using Vaadin 8 deployed on Jboss EAP 7.0 has directory listing issue of all resources within /VAADIN/* e.g /VAADIN/themes/mytheme/images
Validation:
Upon validating other directories, say myapp/images or my/js this issue is not occurring which means default directory listing is off with Jboss configuration and is working perfectly. Issue only with Firefox
Approach:
I could partially fix by having the authentication filter configured for /VAADIN/* URL, but anyways post authentication the directory listing is still happening. Until that fix the listing was happening without authentication
Please suggest a fix the vulnerability
Thank you for the report, we had already noticed some related issues for Vaadin Flow but the tickets or related changes haven't got backported to Vaadin 8 yet. I'll look into it.
The directory listing shouldn't be shown, although the lack of it mainly provides security by obscurity. The files that are served to the client will be accessible through the client regardless. It's best not to include any sensitive data among them.
Edit: Backported fixes should now be available in 8.14-SNAPSHOT and 8.13.2.
I have two environments. 1 online, the other is local.
online is user trial environment: win server 2016, sql server 2016,
IIS 10.0, authorized organization signed SSL certificate. Acumatica
18.000.0062
Local is development environment: windows 10, sql server 2016, IIS
10.0, Self-signed SSL certificate. Acumatica 18.000.0062
Online environment performs properly consistently, no matter for SOAP
service or Restful service(using oath 2.0).
However, Local worked correctly at the beginning, which means the screen-based API worked properly with the WSDL of each screen's web service be generated correctly at that time, and contract-based API responded correctly using cookies mode. Here comes the problem. After I installed self-signed certificate in order to use oath 2.0, both SOAP and rest APIs are crashed with same error "Object reference not set to an instance of an object".
I have digged by myself, the obvious phenomenon that indicating something went wrong is the "tools--web service" to generate WSDL. Before self-assigned certificate be installed, All screens could be generated correctly, after , all screens encountered the same error
Source File: ...\Frames\WsdlHelp.aspx.cs Line: 9
I don't want to be misleading, but these are the details as much as I could provide. What my point is the online and local environment are almost exactly the same, online always works properly even with SSL on. So my large guess is there is something to do with the self-signed certificate. however, even after turned off the https on local IIS, the problem still exists. SO,
Is there anyone can give me some help on this headache issue?
Unfortunately, this is a known issue with Acumatica and .net 4.7.2. It was fixed in 2017R2 Update 8 and 2018R1 Update 2. I'm afraid you have no choice but to either downgrade .net to 4.7.1 or upgrade Acumatica to one of those versions.
I've recently upgraded my Orchard site to version 1.4. Since I had an source code enlistment I just updated to the latest Default branch, and built and deployed the new version. Since the deployment, my blog is totally missing. Thinking it had something to do with the new Autoroute feature, I enabled the Migrate14 module and migrated to 1.4, but still the blog is totally missing in both the Admin UI and at the site.
Do anyone have any ideas on what might have gone wrong?
Check if you have "Blog" feature enabled, this is the first thing.
Second - please check the logs in /App_Data/Logs for any exceptions being thrown and paste your findings here. This could give us a bit more detail.
Third - try upgrading your source to recent 1.x branch. I've been setting up a site using that one yesterday (also upgraded to 1.4) and everything went smoothly.
See this answer's comments for more information related to solution.
I have been developing a small project meant to run under weblogic 8.1.
Richfaces according to documentation states that it supports weblogic 8.1.
Weblogic 8.1 uses servlet specification 2.3 with jsp 1.2
This has been working on my locally installed version of weblogic 8.1 but when deploying to the sparc server, I start running into trouble. I have worked through some of the initial headaches, but then I got an error 500 and couldnt get the details. But after some effort I have come out with this...
javax.servlet.ServletException: javax/servlet/jsp/JspContext
at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:344)
at com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:346)
at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:152)
at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:108)
at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:216)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:107)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:245)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:137)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:214)
at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1072)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:465)
at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:28)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6987)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3892)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2766)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:224)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:183)
JspContext is not part of jsp 1.2 it's newer. I am thinking this exception is originally a ClassNotFoundException or something similar considering the message. There is no 'cause' attached to the exception.
Following are the jar files contained in my web-application.
antlr-2.7.6.jar
asm-1.5.3.jar
asm-attrs-1.5.3.jar
cglib-2.1_3.jar
commons-beanutils-1.6.jar
commons-collections-3.2.jar
commons-digester-1.5.jar
commons-lang-2.4.jar
commons-logging-1.0.3.jar
dom4j-1.6.1.jar
ehcache-1.2.3.jar
hibernate-3.2.4.sp1.jar
jsf-api-1.1_02.jar
jsf-impl-1.1_02.jar
jstl-1.0.jar
jta-1.1.jar
log4j-1.2.15.jar
richfaces-api-3.1.6.SR1.jar
richfaces-impl-3.1.6.SR1.jar
richfaces-ui-3.1.6.SR1.jar
xercesImpl-2.9.1.jar
xml-apis-1.3.04.jar
I'm running out of options, I'll be trying to figure out who has the dependency on the JspContext class... but if someone could give me some insight it would be greatly appreciated. Oh, I cannot make many changes to the production web-logic server. I'd prefer not to make any at all, chances are those changes will be denied
Oh this error occurs when attempting to view the page, so deployment is successful.
Ok, I have solved my problem. Not the way I wanted to but it's working (atleast to what I know right now).
After using google (again) I found a comment with someone mentioning using richfaces 3.0.1.
Now I have seen many people say use version xxx even 3.3.x. After all I did get it working with 3.1.6 but on the windows version of weblogic (which could have possibly been tainted by some other weblogic version I have installed).
So I have modified my pom for maven to depend on:
<groupId>org.richfaces</groupId>
<artifactId>richfaces</artifactId>
<version>3.0.1</version>
This is not optimal, but I geuss it works.
Some taglibrary references needed changing, and packages changed to some extent.
I could post my project configuration for this if anyone ever needs it. Getting this all to work on weblogic 8.1 was not straight forward. But the reference documentation for 3.1.6 is to my knowledge incorrect by saying it support weblogic 8.1
jsp-api-2.1.jar contains the missing class, so you could try using it (either replace it in weblogic, or try in your /lib), but I can't predict what would happen.
I have a problem with IIS 6.0 ceasing to work for an ASP.NET application after installing Service Pack 1 for .NET 3.5.
I have 2 identical virtual dedicated servers. Installing SP1 on the first had no adverse effect. Installing it on the second caused ASP.NET pages to start returning 404 page not found.
Static .html pages working okay on both servers.
Has anybody else experienced this?
This is broad problem, so let's start by asking some troubleshooting questions:
Based on your description, the ASP.NET runtime is not catching your request and processing the aspx files. You may need to register the asp.net pipeline with IIS again using ASPNET_REGIIS -i.
Have you made sure that the app_offline.htm file has been removed
from the directory of the application?
I have had this happen before after an
update.
Have you setup fiddler for instance to follow the request to see what is
exactly being requested?
Make sure ASP.NET is enabled in the IIS Administration Console under "Web
Service Extensions." Make sure everything is set to allowed for your different versions of the framework.
Well, let's start with those and hopefully we can guide you to the problem.
I've seen various people with this problem recently. This link might help.
And this one.
And a few others.
Is CustomErrors in your web.config set to On or RemoteOnly? If so, what do you get when you change it to Off?
I have not had this exact error with .NET 3.5 SP1, but have seen similar occur in the past. Typically it can be resolved by opening a command prompt, going to the appropriate .NET folder and running ASPNET_REGIIS -i. In the case of .NET 3.5 there wasn't an update to the main bits of the framework, so you'd actually go to the .NET 2.0 folder, which on my machine can be found at:
\Windows\Microsoft.Net\framework\v2.0.50727
Running the ASPNET_REGIIS -i will re-register all the ASP.NET libraries with IIS, and should be the equivalent of a re-install of the framework on a given machine (as far as IIS is concerned)
Just to clarify. The last (4th) point given by Dale was the problem. During the installation of SP1 the Status for ASP.NET and WebDAV became set to Prohibited under Web Service Extensions.
Why the installation of SP1 changed this setting on one server and not the other is a mystery that I wouldn't mind (but not expect) an answer to...
The second link provided by CodingTheWheel also had the answer so I'm also going to mark this as an answer.
No-one did before, so I'll point to the trivial solution:
Have you already de-installed the Service Pack and re-installed it again (or the whole framework)?
Edit: #Kev:
Easy explanation: He said the update works on one machine, but not on the other. I had similar problems in the past and re-installing helped to solve some of them. And it is trivial to do.
That's my approach:
1. trivial
2. easy
3. headache
You are right, on productive systems you must be careful, but that's his decision. And because it is a virtual server, maybe it is easy for him to copy it and try as a test environment first.