I've backup of ondemand instance for sugarcrm version 8.0.0 Enterprise Edition
It works normal for CRUD records and other stuff, but when I try to upload module via Zip it gives me following error
Cross Site Request Forgery (XSRF) Attack Detected
Form authentication failure (Administration -> UpgradeWizard). Contact your administrator.
I've tried following article
Troubleshooting Cross-Site Forgery Messages
But the problem still persists. The problem only occurs for BWC modules IMO.
EDIT: Before trying this work-around, check if you have the HTTP referer header disabled in your web browser, as that might be the reason for having the described problem in the first place.
If this is a local test/dev-instance you might want to add
['csrf']['soft_fail_form'] = true,
to your $sugar_config in config.php or config_override.php. That should cause the error to be logged only instead of aborting the action.
Note: This works on Sugar 7.9. I have yet to test it on 8.0.
Source: https://community.sugarcrm.com/community/developer/blog/2017/10/11/upcoming-security-changes-to-sugar
Add this lines in your config_override.php file
$sugar_config['http_referer']['list'][] = 'http://CHANGE_TO_YOUR_LOCAL_URL/';
$sugar_config['csrf']['soft_fail_form'] = true;
Related
I'm trying to connect the SPGo plugin in Visual Studio Code to a Sharepoint Online site. There are lots of guides for this, for instance this one: https://medium.com/niftit-sharepoint-blog/saying-goodbye-to-sharepoint-designer-ac939a0b79ba
In short, I'm doing it like this:
Open VS Code
Open a local, empty folder)
SPGO: Configure workspace (follow guide, ending up with spgo.json
looking like the one I pasted)
SPGO: Populate local workspace (asking me for credentials and I plot
it in O365 style (email and password).
Statusbar says "Populating workspace"
After about 10 seconds I get the pasted error in the output window (spgo)
I'm using newest versions:
Visual Studio Code 1.37.1
SPGo 1.4.3
I have tried various sites in my tenant and I know they are up. I am Site Collection Administrator for the sites. I know the credentials are correct, of course. the remoteFolders and publishingScope doesn't affect anything, when changed. I assume authenticationType should be "Digest".
SPGo.json:
{
"sourceDirectory": "src",
"sharePointSiteUrl": "https://domain.sharepoint.com/sites/SiteName",
"publishingScope": "Major",
"authenticationType": "Digest",
"remoteFolders": [
"/SitePages/"
]
}
I don't get any files in the local folder, instead I get an error in the output:
================================ ERROR ================================
<s:Fault>
<s:Code>
<s:Value>s:Receiver</s:Value>
<s:Subcode>
<s:Value xmlns:a="http://schemas.microsoft.com/net/2005/12/windowscommunicationfoundation/dispatcher">a:InternalServiceFault</s:Value>
</s:Subcode>
</s:Code>
<s:Reason>
<s:Text xml:lang="en-US">The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs.</s:Text>
</s:Reason>
</s:Fault>
Error Detail:
----------------------
{}
===============================================================================
Sorry I missed this post for so long. First- thanks for the detailed write-up. This is the first time I've seen this specific issue with SPGo, so I do not know for sure what is the root cause.
Couple questions:
Are you using ADFS Authentication with your Office 365/SharePoint Online instance?
Are you able to use Addin-Only Authentication on this SP Site?
SPGo should be able to automatically work with ADFS in SharePoint Online but, as a fall-back, you could use Addin-Only Authentication. In this scenario you would create a ClientId and ClientSecret pair for the SharePoint Site Collection you are accessing and authenticate using those credentials. The ClientId would act as your UserName, and the ClientSecret would be your password.
Under the covers, I am using the node-sp-auth package for user authentication. Sergei (s-KaiNet on Github) has a great write-up on how to enable Addin-Only Authentication in SharePoint Online on his site, which you can find here.
Thanks for using SPGo!
We have an api deployed on Azure that uses Google authentication. Over the weekend, the API started to throw 500 errors that were resolved after restarting the API. Is there a way to identify what the underlying cause for these errors might be?
Check if you have custom error mode in web.config file to “on” or “Remoteonly”. If
yes then turn it off. Add the following line to System.web element in web.config
Enable custom logging/instrumentation in the code which can help you in more
information.
ASP.NET applications can use the System.Diagnostics.Trace class to log information to
the application diagnostics log. For example
System.Diagnostics.Trace.TraceError("If you're seeing this, something bad happened");
Enable Detailed Error Messages - Detailed version of the html files produced when
your website responds with an error message. This is good to enable for debugging
some error responses in your website. It is stored in the website's file system.
Web Server Logging - Also known as HTTP logs or IIS logs, this will log all requests
to your website in W3C Extended Log File Format.
Failed Request Tracing - Also known as FREB, here you can get lots of information
from IIS through its different stacks for each failing request.
We have an ASP.Net/angular/web api on IIS 7.5 that is being called with bad encoding and we're trying to get the request body logged so we can show the problem to the caller.
We googled around and found ModSecurity, so we installed it and are giving it a try - but only for the Audit Logging portion. Unfortunately, neither C nor I seem to be logging anything, no matter what we do. I've seen some other Oflow posts that I infer to mean ModSecurity only logs those types for certain incoming requests (.html logs C but nothing else does kind of thing). WebApi and angular might be confusing it, but I'm not sure. Nothing I've tried seems to work.
Here's our configuration:
# -- Audit log configuration -------------------------------------------------
# Log the transactions that are marked by a rule, as well as those that
# trigger a server error (determined by a 5xx or 4xx, excluding 404,
# level response status codes).
#
SecAuditEngine On
SecRequestBodyAccess On
# Log everything we know about a transaction.
SecAuditLogParts ABCIJDEFHZ
# Use a single file for logging. This is much easier to look at, but
# assumes that you will use the audit log only ocassionally.
#
SecAuditLogType Serial
SecAuditLog E:\ModLogs\modsec_audit4.log
Is there something else I've got to do to get ModSecurity to do the C/I logging?
ModSecurity 2.9.1 (downloaded today), IIS 7.5, Web Api, Angular, ASP.Net
Thanks
This looks to be a known bug with ModSecurity and IIS: https://github.com/SpiderLabs/ModSecurity/issues/538
Near the bottom of that bug there are comments that this can be resolved by setting this in your config:
SecStreamInBodyInspection On
There are also some posts suggesting disabling DynamicCompression in IIS is necessary.
We are using WSO2 Carbon 4.2.0 through the WSO2 Application Server (AS) package. In replacing an older, highly customized Carbon installation (provided by a company that no longer supports the product, has abandoned it and refuses to work on it, and left us no details on how/what they modified in Carbon), we have deployed a couple web applications in the webapps container as they were deployed before in the older instance. We have changed our WebContextRoot in the carbon.xml from the default "/" to a sub-URL of ex: "/stuff", as is also detailed in the self-answered SO question here. However the answer given there is not detailed in what the OP actually encountered when he modified his WSO2 instance.
In testing the above configuration we noticed that if a user were to go to a non-existent web address on the server, depending on the format of the URL they are either:
redirected to a blank page;
receive a "500 Internal server error" (I suspect this is the embedded Tomcat?);
get sent to the Carbon login page (which we definitely do not want to happen for security reasons); or
get an XML document stating:
<faultString> The service cannot be found for the endpoint reference (EPR) /stuff/services/nonexistantservicename </faultString>
At least in the case of missing content we wish the user to be sent to a standardized 404 error page, or at the least be sent an HTTP 404 error by the server. For services the XML error is palatable, we can deal with that.
The only option for us right now to circumvent this issue is to place a proxy in front of the WSO2 instance, which would be another layer to manage and tune, and possibly degrade performance. Please know that I am not a programmer but just an admin with DevOps experience. I would not know how to handle this with e.g. a Java solution or re-coding parts of WSO2. Customizing the core product would also hamper future upgrades of WSO2, a scenario we are trying to dig ourselves out of now as detailed above. Is there no internal WSO2 mechanism to handle non-existent content? Can we not redirect any errors to a standard canned response page?
This problem seems to exist on a specific server. All other servers are working ok.
Background: The website is basically Forms Auth but there's an asmx that manually requires Basic Auth.
I have two C# client.
When invoking using SOAP (asmx client proxy) with basic auth credentials - all is well.
When invoking using WebClient or WebRequest with the same basic auth credentials, I get 401.5.
The folders have "Everyone" set to them.
When setting up iis trace, I see a very weird behavior. The request arrives with the correct Basic auth header. But further down the trace I see the following:
GENERAL_REQUEST_HEADERS
Headers="Connection: Keep-Alive
Content-Length: 68
Content-Type: application/json
Authorization: Kerberos
Expect: 100-continue
Host: 1.2.3.4
The Kerberos seems very weird. It is as if the request headers changed throughout the process, and perhaps that explains the 401.5.
Again, I would like to stress out that on other servers there's no problem with both clients. The only difference I can think of is that the problematic server is a DC. But if that is a problem then why is the SOAP client working well?
Any ideas?
Progress!
After some debugging I noticed that Application_AuthenticateRequest was fired twice for every request. The first time with Basic auth as I expected and the second time with the Kerberos!
After googling I found this:
http://forums.asp.net/t/1868629.aspx?HttpModule+triggered+two+times+for+request+to+URL+without+default+document
Seems like for extensionless urls those events might fire multiple times, depending on the configured Extensionless urls.
Going back to the trace I noticed that in the non-working server the trace shows usage of ExtensionlessUrl-ISAPI-4.0_64bit, and in the working servers no such entry existed. After comparing the two IIS I noticed that the non-working IIS had ExtensionlessUrl-ISAPI-4.0_64bit configured whereas in the working IIS there was ExtensionlessUrl**Handler**-ISAPI-4.0_64bit (note the "handler"). I compared the dlls involved and the working server had a newer aspnet_isapi.dll. I assume that this is an updated extensionless url handler. I suppose an upgrade to IIS or .NET might install a later version, but for now I tried to remove the ExtensionlessUrl-ISAPI-4.0_xxbit like so:
<remove name="ExtensionlessUrl-ISAPI-4.0_32bit" />
<remove name="ExtensionlessUrl-ISAPI-4.0_64bit" />
And it worked! Now there is only a single Application_AuthenticateRequest.
The non-working version that had this in the trace:
OldHandlerName="", NewHandlerName="ExtensionlessUrl-ISAPI-4.0_64bit", NewHandlerModules="IsapiModule", NewHandlerScriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll", NewHandlerType=""
Now changed to:
OldHandlerName="", NewHandlerName="WebServiceHandlerFactory-ISAPI-4.0_64bit", NewHandlerModules="IsapiModule", NewHandlerScriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll", NewHandlerType=""
Hopefully that's the end of it. Additional testing still required.
I would appreciate if someone can write how to upgrade IIS dlls to a later version. Is this an upgrade to .NET or is there a specific KB update that is downloaded with Windows Update?