In the process of tracking down an elusive Sharepoint custom workflow problem, I cranked up the verbosity level on our sandbox MOSS server and noticed the following error message start popping up:
SPSite should not be used with mixed impersonation state. If you do want to cache an SPSite created within RunWithElevatedPrivileges, call SPSite.BypassImpersonationStateCheck
While this is most likely unrelated to our problem, I was curious about this SPSite.BypassImpersonationStateCheck method that doesn't seem to actually exist. When we include this call in our code it won't compile. MSDN doesn't have any information. A quick Google search doesn't turn up any concrete answers. What is SPSite.BypassImpersonationStateCheck?
Related
I have been extensively using a custom protocol on all our internal apps to open any type of document (CAD, CAM, PDF, etc.), to open File Explorer and select a specific file, and to run other applications.
Years ago I defined one myprotocol protocol that executes C:\Windows\System32\wscript.exe passing the name of my VBScript and whatever argument each request has. The first argument passed to the script describe the type of action (OpenDocument, ShowFileInFileExplorer, ExportBOM, etc.), the following arguments are passed to the action.
Everything worked well until last year, when wscript.exe stopped working (see here for details). I fixed that problem by copying it to wscript2.exe. Creating a copy is now a step in the standard configuration of all our computers and using wscript2.exe is now the official configuration of our custom protocol. (Our anti-virus customer support couldn't find anything that interacts with wscript.exe).
Today, after building a new computer, we found out that:
Firefox doesn't see wscript2.exe. If I click on a custom protocol link, then click on the browse button and open the folder, I only see a small subset of .exe files, which includes wscript.exe, but doesn't include wscript2.exe (I don't know how recent this problem is because I don't personally use FireFox).
Firefox sees wscript.exe, but it still doesn't work (same behavior as described in my previous post linked above)
Chrome works with wscript2.exe, but now it always asks for confirmation. According to this article this seems to be the new approach, and things could change again soon. Clicking on a confirmation box every time is a big no-no with my users. This would slow down many workflows that require quickly clicking hundreds of links on a page and, for example, look at a CAD application zooming to one geometry in a large drawing.
I already fixed one problem last year, I am dealing with another one now, and reading that article scares me and makes me think that more problems will arise soon.
So here is the question: is there an alternative to using custom protocols?
I am not working on a web app for public consumption. My custom protocol requires the VBScript file, the applications that the script uses and tons of network shared folders. They are only used in our internal network and the computers that use them are manually configured.
First of all, that's super risky even if it's on internal network only. Unless computers/users/browsers are locked out of internet, it is possible that someone guesses or finds out your protocol's name, sends link to someone in your company and causes a lot of trouble (possibly loss too).
Anyway...
Since you are controlling software on all of the computers, you could add a mini-server on every machine, listening to localhost only, that simply calls your script. Then define host like secret.myprotocol to point to that server, e.g., localhost:1234.
Just to lessen potential problems a bit, local server would use HTTPS only, with proper certificate, HSTS and HPKP set to a very long time (since you control software, you can refresh those when needed). The last two, just in case someone tries to setup the same domain and, for whatever reason, host override doesn't work and user ends up calling a hostile server.
So, links would have to change from myprotocol://whatever to https://secret.myprotocol/whatever.
It does introduce new attack surface ("mini-server"), but should be easy enough to implement, to minimize size of that surface :). "Mini-server" does not even have to be real www server, a simple script that can listen on socket and call wscript.exe would do (unless you need to pass more info to it).
Real server has more code that can have bugs in it, but also allows to add more things, for example a "pass through" page, that shows info "Opening document X in 3 seconds..." and a "cancel" button.
It could also require session login of some kind (just to be sure it's user who requests action, and not something else).
The title of this blog post says it all: Browser Architecture: Web-to-App Communication Overview.
It describes a list of Web-to-App Communication techniques and links to dedicated posts for some of them.
The first in the list is Application Protocols, which I have been using for years already, and it started to crumble in the last year or so (hence my question).
The fifth is Local Web Server, which is the one described by ahwayakchih.
UPDATE (this update follows the update on the blog post above mentioned)
Apparently I wasn't the only one thinking that this change in behavior was a regression, so a workaround has been issued: the old behavior (showing a checkbox that allows to remember the answer) can be restored by adding these keys to the registry:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge]
"ExternalProtocolDialogShowAlwaysOpenCheckbox"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"ExternalProtocolDialogShowAlwaysOpenCheckbox"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Chromium]
"ExternalProtocolDialogShowAlwaysOpenCheckbox"=dword:00000001
[Disclaimer: I'm not sure if this kind of question is accepted here as it is about a piece of software deployed already. Rest assured I didn't drop any confidential information. Also do tell me if I violated any rules in SO by posting this so I can take it down immediately]
I have a working Learning Management System web application and I recently received a bug report about a button not showing. After investigating, I have proved that the user was not using the web app as intended. When taking an exam, he was opening multiple tabs to exploit the feature that informs him whether the answer was correct or not. He then will use this information to eliminate the wrong answers and submit all the right answers in another tab/window.
I'm using Rails 4.2. Is there a way to prevent multi-tab browsing? I'm thinking like if a user is signed in and he attempted to open a new tab of the webapp, he should see something like "Please use one tab" and all the features/hyperlinks/buttons are disabled.
Here's a screenshot of how I proved he was using multiple tabs. Notice that there are multiple logs of the same attempt # because the current implementation allows saving a study session and resuming later (this is the part that's exploited). The opening of multiple tabs searches for the most recent attempt session and continues from there. This is also the reason why most of the sessions don't have a duration value -- the user only finishes a study session for one tab (by clicking a button that ends the study session). The system cannot compute for the duration because the other sessions don't have an end timestamp.
-
This is what a single-tab user looks like:
This is more of an application misuse issue more than a bug.
You should add protection not only from multi tab, but for multi browsers aw well, so it can't be purely FrontEnd check.
One of the solutions could be using ActionCable to check if a user has an active connection already and then act accordingly.
Another, for example, generate a GUID in JS and pass it with every answer. If its different from previous answer, it means user opened a new window.
But of course the solution would depend on your current architecture, without knowing how do you currently organise client-server communication it's hard to give exact and optimal solution.
I found an answer here. I just placed this js in the application view to prevent any extra instance of the website.
Thanks for everyone who pitched in.
We've noticed a very strange behavior change on our website (asp.net MVC) starting early morning (GMT) on the 12'th of January this year (2018).
Http POSTs from the site started firing twice (unconfirmed, but we suspect sometimes more than twice), and scouring high and low we couldn't find that we'd changed anything.
One of the few things we dynamically load is Google Analytics (specifically Google Tag Manager), and in the course of trial-and-error we tried disabling everything external (which made the phenomenon disappear) and then re-enabling them one-by-one, once we came to re-enabling GA the problem re-appeared.
We also tried removing everything except GA and the problem persisted.
When searching we can't find that anything has been updated in GA, so it's very unclear why it suddenly started, and we have also been unable to find anyone else reporting the same problem (either historically or presently).
Our current best guess is that one of GA's dependencies have updated, and either it contains a bug, or it's exposing an already existing fault in our code.
Has anyone else noticed the same problem? Anyone find something in their code that caused the strange behavior of GA?
I found the error, it was caused by two erroneously set up triggers.
Both triggers were form submit type, and both had double activators, one "Activate trigger when all conditions are met" and one "Activate trigger on specific forms".
The problem was that both "all conditions" activators were set to "url matches regular expression .*", where as the second activator for both targeted a correct Form Path for each respectively.
Whoever set it up must have assumed that Google Tag Manager was using a logical "and" between the two activators (not an unrealistic assumption), but based on my testing at least it seems that the trigger activates on either activator matching.
I couldn't see any reason for the first regex match towards ".*", so the fix was to simply supply a unique url expression for each trigger.
No explanation yet as to why it suddenly became a problem, because the configuration has been wrong for a couple of months at least.
P.S. For whatever reason our GTM is not in English, so take my quoted names on fields/etc with a grain of salt as they are translated.
Update
The website uses ajax to post the forms, the combination of that and the "Await tags" flag on the triggers are looking as likely sources of why the combined conditions were not acting as expected.
Which means a non-announced performance-update to GTM regarding "Await tags" could have been the catalyst which caused the problem to start occuring with alarming frequency.
A customer has a number of XPages applications that have a jQuery Mobile user interface for use on iPads. They have been working fine for a long time. There have been no application code changes, but recently users are reporting strange behaviour in the user interface across a number of the applications.
This seems to be related to multi-value fields where JQM shows a long list of values in an overlay. When then selecting a second multi-value field the pop-up box is being displayed but then immediately replaced with the overlay for the first field but without any values.
The Domino server is 8.5.3 FP4 and the administrators tell me there have been no environment and security changes recently.
In addition to the above I am also seeing the following errors occurring :-
16/12/15 15:54: Exception Thrown
com.ibm.xsp.acl.NoAccessSignal
at com.ibm.domino.xsp.module.nsf.NotesContext.checkAccess(NotesContext.java:1631)
at com.ibm.domino.xsp.module.nsf.NotesContext.serverProcessSignedResource(NotesContext.java:975)
at com.ibm.domino.xsp.module.nsf.NotesContext.setSignerSessionRights(NotesContext.java:946)
at com.ibm.domino.xsp.module.nsf.ModuleClassLoader$DynamicClassLoader.loadClass(ModuleClassLoader.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:626)
at com.ibm.domino.xsp.module.nsf.ModuleClassLoader.loadClass(ModuleClassLoader.java:171)
at java.lang.ClassLoader.loadClass(ClassLoader.java:626)
at com.ibm.designer.runtime.Application.loadClass(Application.java:708)
at com.ibm.xsp.library.ApplicationFacesClassLoader.loadClass(ApplicationFacesClassLoader.java:54)
at com.ibm.xsp.page.compiled.CompiledPageDriver.getClassForPageName(CompiledPageDriver.java:169)
at com.ibm.xsp.page.compiled.CompiledPageDriver.loadPage(CompiledPageDriver.java:61)
at com.ibm.xsp.application.ViewHandlerExImpl._createViewRoot(ViewHandlerExImpl.java:489)
at com.ibm.xsp.application.ViewHandlerExImpl.createViewRoot(ViewHandlerExImpl.java:557)
at com.ibm.xsp.application.ViewHandlerExImpl.doCreateView(ViewHandlerExImpl.java:141)
at com.ibm.xsp.application.ViewHandlerEx.createView(ViewHandlerEx.java:90)
at com.ibm.xsp.webapp.FacesServlet.serviceView(FacesServlet.java:238)
at com.ibm.xsp.webapp.FacesServletEx.serviceView(FacesServletEx.java:204)
at com.ibm.xsp.webapp.FacesServlet.service(FacesServlet.java:160)
at com.ibm.xsp.webapp.FacesServletEx.service(FacesServletEx.java:138)
at com.ibm.xsp.webapp.DesignerFacesServlet.service(DesignerFacesServlet.java:103)
at com.ibm.designer.runtime.domino.adapter.ComponentModule.invokeServlet(ComponentModule.java:583)
at com.ibm.domino.xsp.module.nsf.NSFComponentModule.invokeServlet(NSFComponentModule.java:1281)
at com.ibm.designer.runtime.domino.adapter.ComponentModule$AdapterInvoker.invokeServlet(ComponentModule.java:860)
at com.ibm.designer.runtime.domino.adapter.ComponentModule$ServletInvoker.doService(ComponentModule.java:803)
at com.ibm.designer.runtime.domino.adapter.ComponentModule.doService(ComponentModule.java:572)
at com.ibm.domino.xsp.module.nsf.NSFComponentModule.doService(NSFComponentModule.java:1265)
at com.ibm.domino.xsp.module.nsf.NSFService.doServiceInternal(NSFService.java:658)
at com.ibm.domino.xsp.module.nsf.NSFService.doService(NSFService.java:481)
at com.ibm.designer.runtime.domino.adapter.LCDEnvironment.doService(LCDEnvironment.java:341)
at com.ibm.designer.runtime.domino.adapter.LCDEnvironment.service(LCDEnvironment.java:297)
at com.ibm.domino.xsp.bridge.http.engine.XspCmdManager.service(XspCmdManager.java:272)
There doesn't seem to be any indication as to which application or XPage these exceptions are related to. And I do not know whether this is related to the issues being seen in the user interface of the various applications.
Can anyone shed any light on this exception or what I should be looking for?
What jumps out are these lines:
at com.ibm.domino.xsp.module.nsf.NotesContext.serverProcessSignedResource(NotesContext.java:975)
at com.ibm.domino.xsp.module.nsf.NotesContext.setSignerSessionRights(NotesContext.java:946)
I don't know which application is causing the problem, but it looks it may be having a problem assigning signer rights. It may be worth checking for multiple signers of design elements.
The com.ibm.xsp.acl.NoAccessSignal exception is thrown when an anonymous user tries to access a protected XPages resource. So this exception has nothing to do with the strange behaviour that you are experiencing.
Hello stackoverflow world.
(This is the first time I actually post a question here. Exciting)
A while ago I inherited a 2 year old MVC website from one of the teams within my corporation. I know most the ins and outs of this solution now but there is something strange cropping up in my error logs which I do not understand.
Every now and then I will get an error messages like this one:
A public action method 'xyz.gif' could not be found on controller MyNamespace.MyController
What I don't understand is WHY is this action (a gif image) being called in the first place?
I've seen 2 different gifs in the error logs pageerror.gif and refresh.gif
As this is an inherited solution I double checked everything and made sure that there are in fact no images like that in the project and no reference anywhere even to those words in the controllers, views, style-sheets or even in the source of pages within the same controller.
I seriously doubt that the users are playing around with the URLs and adding random gif names to them to see what happens.
I'm all out of ideas. Anyone out there who can suggest more places to look for the culprit?
Ta!
As Tchami pointed out in a comment on the original question, this is related to Internet Explorer's default error pages.
As I have set up custom error pages I believe this is either due to an internal server error or possibly somehow an action cancel error from the client side, i.e. client side error. I can't be 100% at this point.
The question is not fully answered but I mostly know what the cause is now.
From my point of view I've identified that I need to improve this ASP.NET MVC application so that
1) it doesn't report/log errors when someone tries to navigate to a non-existing controller action (e.g. these refresh.gif actions or any other)
and 2) handle it better for the client so that they don't end up clicking from one error page (default IE error page) to another (my custom error page when clicking the refresh icon on the IE page)
Another stackoverflow thread on a related topic:
Significance of 'pagerror.gif'?
(i can't post more links as I'm a new user)
CHEERS!
Solveig
Can you get the error to show up in the logs when you use the site yourself? If so, an add-in such as HttpWatch might help you see those .gif requests. If you can understand more about when they happen you might be able to figure out what's going on.
Pagerror.gif and refresh.gif are the default images from the IE browser/IIS server. Normally these images were shown when the browser is not able to retrieve the content.
If you see these errors in logs, then check the iis log to get more information.
For example,
IIS Log : look for this feild ,
cs(User-Agent)
compatible;+MSIE+6.0;+Windows
Here few things to be noted,
1)IE 6.0 apparently makes these requests on its own. I am not sure if any other IE 6+ Browser would show similar behavior.
2)All this will do is generates a 'bogus" event log entry because a null reference exception could happens when you request a non-existing GIF and that request goes through MVC pipeline.
3)Technically this simply can be ignored.
4) Optionally we could check if through routing we could stop “.gif” files from being processed by MVC Pipeline
All i would suggest is to handle it gracefully.
It may be difficult to pinpoint this, but my thought would be: check the javascript. If the image name is being dynamically generated somewhere, and then requested, a simple "find and replace" may miss the reference.