We developed a web application using sharepoint 2013. We used rdlc reports for reports. I configured these reports in lower environments, it's working as expected. But when I deployed the code in production environment it's not working. I am getting Asp.net session is expired or could not be found. FYI, in prod we have load balancers with two server nodes and session state as inproc
Maybe your problem is the forms authentication name attribute.
The name attribute make different applications use the same authentication in asp.net ecosystem.
It's in Portuguese, but the example can help you: https://www.rcelebrone.com/2017/09/forms-authentication-nao-mentem.html?m=1
Related
I recently updated my environment from WSO2 IS 5.0.0 to WSO2 IS 5.2.0. My environment consists of one machine deployed on EC2 AWS instance. I am using MySQL(not the default H2 database). The machine on which the IS is deployed is Windows Server 2012 R2.
I also have a solution which wraps the IS Admin Soap services and allows me to automate some of the processes like:
-- Service Provider creation and configuration
-- User creation and configuration
-- Tenant creation and configuration
After upgrading to WSO2 IS 5.2.0 I started experiencing delays in the responses of the admin SOAP Services. Since I am using AWS I double checked whether I am using the most appropriate region to have the IS machine. Indeed it was - I am using the Frankfurt region.
I decided to do a simple test to see whether there is delay and if so how it affect my applications. So I created a simple Console Application which was hosted on my local machine and configured the Service References first against my new DEV IS 5.2.0 machine(Frankfurt region). For my test purposes I am using RemoteUserStoreManagerService?wsdl and I am trying to create a user. Ran the test several times and it seems that it takes about 6-7 seconds to create user.
Then I used the exact same conditions in order to run the test against DEV IS 5.0.0 machine which is also hosted in the same region (Frankfurt) and is using the exact same machine configuration (t2.large). Once again the Console Application was hosted on my local machine. The result from the second test was - 1 second to create the user using the very same admin SOAP service and the exact same logic in the Console Application under the same conditions the first test was executed.
Please find below image that displays some of the test results:
https://www.dropbox.com/s/h6rrhnczrutmmxw/IS5.2%20vs%20IS%205.0%20SOAP%20Service.png?dl=0
Is this a known behavior, or some sort of configuration should be applied to avoid such delays from the admin SOAP services?
Thanks in advance.
It turned out to be a configuration issue. In the following file:
"[wso2is-5.2.0_HOME]\repository\conf\identity\identity.xml"
There is a section named "EventListeners" and in there the following listener:
<EventListener type="org.wso2.carbon.user.core.listener.UserOperationEventListener" name="org.wso2.carbon.identity.mgt.IdentityMgtEventListener" orderId="50" enable="true"/>
Once I disabled this listener, all my issues regarding the delays in the responses of the SOAP admin services disappeared.
I did basic search to see what is the purpose of this listener and was able ti find the following:
http://pushpalankajaya.blogspot.bg/2016/02/account-deactivation-with-wso2-identity.html
I have been working with Azure's web app service using Resource Manager to deploy a Django app. It has been working in fits and starts. I really like the auto-deployment from GitHub but I have been frustrated by the ability to work with the underlying machine. There is a "Console" tool through the Azure portal but it has limited functionality and when there is an internal server error on my app, I can't find the server output log.
Can someone share insight into how to view the server logs?
Azure web apps have a number of logs however, the applications logs provided out of the box only support Asp.Net applications. That being said there is an article about django on web apps and how to store and view its logs here.
What'll you'll have to do, as described in the link, is to setup the django application to store its logs on the azure file system. Another option is to setup the django application to email the devs but the better option is to store the logs on the file system properly.
I have a provider hosted app (a normal asp.net web forms application) deployed on a typical web server IIS 7.5.
While launching the app from SharePoint Site in Office 365 Multi Tenant, it's throwing the below issue on App launch.
On capturing details using Fiddler, found the following when the app is launched
SPAppToken=&SPSiteUrl=https%3A%2F%2Fabc.sharepoint.com%2Fsites%2Fspdev%2Famsdev%2Famitamsdev&SPSiteTitle=amitamsdev&SPSiteLogoUrl=%2Fsites%2Fspdev%2FSiteAssets%2Flogo.gif&SPSiteLanguage=en-US&SPSiteCulture=en-US&SPRedirectMessage=EndpointAuthorityMatches&SPCorrelationId=31477a9c-2902-204a-8393-67eced1a10b8&SPErrorCorrelationId=31477a9c-2902-204a-8393-67eced1a10b8&
SPErrorInfo=The+requested+operation+requires+an+HTTPS+%28SSL%29+channel.++Ensure+that+the+target+endpoint+address+supports+SSL+and+try+again.++Target+endpoint+address
The SPErrorInfo Part is interesting. I am unable to confirm whether we really need the remote site to be configured for https?
Additional Information - Identity Provider is ACS and it is a low trust app.
Can someone suggest?
Regards,
Nitin Rastogi
In a production environment, you should always be using HTTPS. If you don't, you're exposing yourself (and your organization) to many risks.
If this is your development environment and you are confident this isn't an issue, you may want to look at the accepted answer to this question on the MSDN forums, which mentions the same error message. Their solution to bypass the HTTPS checking:
$c = Get-SPSecurityTokenServiceConfig
$c.AllowMetadataOverHttp = $true
$c.AllowOAuthOverHttp=$true
$c.Update()
When packaging the SharePoint App from Visual Studio, you must ensure that the URL you use is using HTTPS:
In IIS, add an HTTPS binding to the site to achieve this. You would have to reupload the App to SharePoint after packaging it with the new HTTPS URL.
More information here.
I have asp.net web service application created in VS 2010. I created this web service using ASP.NET Web Service Application template in VS 2010. My InfoPath form consumes my webservice. However to fill out my IP form, I first have to make sure I run my web service, otherwise I get errors like cannot connect to the webservice.
How can I make sure my web services are properly deployed to my SharePoint site that hosts infoPath form services? Please let me know the necessary steps. If my web services are deployed to my SharePoint site then there's no need to manually run my asp.net web service in the browser everytime I need to fill out the form. Thanks.
Here's the error message I got when I tried to browse my custom web service deployed to layouts folder:
http://abcd/_layouts/WebServiceDemo/MyCustomWebService.asmx
I couldn't find relevant message in 14-->LOGS. Any idea what's causing this? Thanks.
My own analysis: Please visit the web.config inside LAYOUTS folder and set Customerros to Off to get more meaningful error message.
I Googled "How to consume asp.net web service in SharePoint site".
The third hit was Walkthrough: Creating a Custom ASP.NET (ASMX) Web Service in SharePoint 2010. The post shows how to create, deploy and consume the service.
I'm getting an error when attempting to call SharePoint's webservices on one of our platforms. To start, we have Development (DEV), Testing (QA) and Production (PROD) SharePoint servers. The QA and PROD servers are pretty much identical. We have an ASP.NET web service that sits out as a seperate application on each of them. Our data entry forms hit the web services to insert/update into a SQL database and in some cases make calls to some of SharePoints web services (lists, dws).
We’re having trouble calling SharePoint’s web services on PROD from our web services however, have no problems on QA(or DEV). In our web service code we have a web reference to the SharePoint web services (lists and dws). We attempt to call these web services to create list items/folders when a new entry is made through one of our forms. On QA, there is no problem creating the list items/folder. The form is filled out, calls our web services – which call the SharePoint web services and the list item/folder is created.
On PROD we get the following error when we attempt to call the SharePoint web services:
Unable to connect to the remote server
at System.Net.HttpWebRequest.GetRequestStream()
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
...
However, to make it more interesting, if I call the PROD SharePoint web services directly from my personal computer I have no problem creating the list items/folders. We only have the problem when our web service attempts to call the PROD SharePoint web services. We’ve looked through many different web.config files looking for differences on QA and PROD and are yet to come up with anything.
If anyone has any pointers, they would be greatly apppreciated. Thanks.
Update: I just attempted to refactor the above method to use the SharePoint Object Model API and I'm getting an unauthorized error. When using the Object Model API the credentials do not seemed to be passed properly, because it's attempting to use the MOSS Server credentials. Is there any way to tell it which credentials to use as you do with the web service api?
docLibList.Credentials = System.Net.CredentialCache.DefaultCredentials;
Thanks.
Sean,
I'm not sure I completely understand your calling pattern, but if you are indeed looping back to web services on the same box, you might be running into the infamous loopback issue:
https://serverfault.com/questions/32345/ie-8-authentication-denied-on-local-sharepoint-site/32485#32485
In short: executing hostname-based HTTP calls that loopback to the server from which they're issued can get blocked. If the loopback issue is in-play, you'll be able to call the web services in PROD from another box ... but not from the PROD box itself (i.e., looping back). I think this is consistent with the behavior you described above.
If Windows patch levels are different between your environments, it might explain why your code is failing in PROD but not in your other environments.
I hope this helps!
This probably is not the problem, but is your reference to the web service pointing to the production server correctly. I had a problem before when trying to access a SP service that was referenced incorrectly. The dev server I was pointing to was on a seperate domain and could not be found.
Regarding the update to your question about the unauthorized error using the object model:
Depending on the context that your code runs in you will sometimes need to elevate privileges. See this Elevation of Privilege MSDN article for details (also note the community comment at the end). There's also a Visual How-To.
Another method is to create a new SPSite object using a SPUserToken object. There is more information in this blog post by Daniel Larson. For the system account this would be done with the code:
SPSite site = new SPSite(SPContext.Current.Site.ID,
SPContext.Current.Site.SystemAccount.UserToken);
By the way, this would be better in its own question next time so that it can be correctly voted and answered.