Hmm... we didn't recognise that application error message - xero-api

I've been implementing the API sample from GitHub. In my development environment I can logon using the OAuth method, and obtain a token and perform the query request on the XERO. If I deploy, I can't get the application to work because of the errormessage 'Hmm... we didn't recognise that application.' I can logon, then select the instance to work upon and then the error message appears. For some reason i can't obtain a token:
I get a https://app.xero.com/oauth/APIAuthorise?oauth_token=
message, in my dev env. I get a token.
I found several posts regarding this message on the Xero forum. It is written that it has to do with TLS and I should upgrade to 1.2 My issue is that my connection is already tls1.2, I verified. I tried two different hosts to do an extra check but with the same result (virtual windows 2008 server and Linux)
The Question is how to solve this issue. Again my application is working well on development, but not when I deploy. The development system is running under W10 / Xampp and PHP 7.2. My production environments are a regular Linux host (not sure what) and a virtual Windows 2008 server with uniform server.
The code is very similar to the original sample as published on GitHub, so I didn't post it here.

Related

IIS can only support three instances of a Blazor server client?

I've download Visual Studio 2022 and tested the default Blazor Server template (Home/Counter/FetchData). In Visual Studio, IIS Express I can open as many tabs / instances of the application as I want.
When I host the default Blazor Server template in local IIS (Windows 10 Home 21H2, IIS 10) I can only open three instance of the application. The fourth will hang until the first is closed. I see someone has ran into nearly the exact same issue but there is no solution provided.
Anyone know whats going on? I don't understand why IIS Express can handle multiple instnaces but IIS 10 can not. Even Conveyor by Keyoti can support many many tabs compared to IIS 10.
Note: I notice SignalR has limitations on Windows / IIS of 10 concurrent connections, but I'm not even getting two.
Updates
Out of curiosity I tested it on Windows Server 2016 Standard and I can open hundreds of tabs.
I re-installed IIS on Windows 10 to make sure something wasn't wacky.
I've ensured WebSocket Protocol is enabled.
Windows 10 Home supports 3 concurrent connections at the same time, according to Microsoft.
Normal HTTP requests to IIS get process and response returned. So even if you manage to achieve 4 or more at the same time, IIS will work through the request queue and you may not have noticed that your request was slightly delayed unless your individual requests take a while to process.
However with SignalR, a persistent connection is maintained to the server. So if you open one connection per browser tab, and you have 4 tabs open, that 4th tab is going to hang indefinitely until one of the other page has its connection ended (by closing the tab, manually disconnecting via code, or refreshing the page).
I can't reproduce the issue, and I have tried to search some way to solve it.I will summarize a few ways below that you can try.
Try to install Websocket Protocol in your Win10. You can find it in Windows features.
Workaround: install IIS Express in Web Platform Installer.
Workaround: Try to deploy it in windows server, and check whether have same issue. I found some posts also mentioned it may related with OS version.
The solution was incredibly simple (maybe too simple?). Don't use IIS at all.
In Program.cs just before building the app I override Kestrel ports to listen on any ip (for now).
(Optional) I provide a custom SSL certificate in the UseHttps constructor so that it can be emailed and installed on iOS and Android devices.
(Required) Then I publish the applications to a folder and just run the .exe on the hosting machines.
Program.cs
builder.WebHost.ConfigureKestrel(opt =>
{
opt.ListenAnyIP(8000);
opt.ListenAnyIP(8001, listOpt =>
{
listOpt.UseHttps(#"Path to.pfx file", "password for pfx file");
});
});
Now Windows 10 Home can support as many connections as the hardware can handle at https://192.168.0.XXX:8001. Is this how Blazor Server is expected to be deployed within a local network? I don't understand how this overcomes the connection limit pointed out in masons answer. Please let me know in the comments if I'm missing something.

IIS pool stops on first request

I have .net framework 4.8 web site deployed on IIS 10. And It's pool stops on every first request after each start.
Here is the list of programs and features on server:
Programs and features
In Application Windows log I found 10 errors per each request. Everyone error is:
The Module DLL C:\Windows\system32\inetsrv\aspnetcore.dll failed to
load. The data is the error.
And in System log I have warning:
A listener channel for protocol 'http' in worker process '2968' serving application pool '{MyPoolName}' reported a listener channel failure. The data field contains the error number.
With binary data in details tab: In Words 0000: 8007007E
I tried to repair installed version of .net 5. Also tried to install .net framework 4.8, but installer didn't allow to do it because of:
.NET Framework 4.8 or a later update is already installed on this
computer.
I even tried to create site with empty directory. When I create one on my computer it shows "403.14 — Forbidden" as it should. But after doing the same on server empty site pool stops as my site's pool.
Have you ever faced such a problem? I have no idea how to fix it!
I have .net framework 4.8 web site deployed on IIS 10. And my IIS pool stopped on first request. Researching similair issues I found this artcle on the Microsoft Monitoring Agent APM service. This service was disabled, I removed the Microsoft Monitoring Agent APM as it was not being used. My application now successfully launches.
https://kevingreeneitblog.blogspot.com/2017/03/scom-2016-agent-crashing-legacy-iis.html
Thank you for your help. I solve the problem with complete reinstallation of server OS and components. My consider is that the problem was into iis or OS component.

Encountering Kerberos and/or NTLM authentication failures in custom application packages written using the WISE packaging Installer

We are encountering Kerberos and/or NTLM authentication failures in custom application packages orinally designed for Windows 7 using the WISE packaging Installer. On Windows 7 they work fine but they now fail on Windows 10. They fail both during installations on Windows 10 using the Microsoft SCCM tool, and they fail specifically when using Kerberos authentication to an SMB Share on the network durign the installation process. We can see inside the network trace that the client application fails over to NTLM from Kerberos durign the authentcation transaction. We are unsure why. We have a large scale Active Directory environment. Because the WISE package is comiled we cannot look into it. On successful Windows 7 machines, it appears the computer requires access to the Share while the package is being executed and the loggged-in user must have read and execute access on the SMB Share. We are able to access the same SMB Share using the Windows 7 system account but not when using the Windows 10 system account. Very odd! Is this a code issue inside the package? This may be important: The SMB share is using an DNS alias, not sure if this makes any difference. The real name of the host is different. When using the real name of the host instead of the alias the access issue appears to be resolved.
The network share wouldn't happen to be hosted by a non-Windows server by any chance, would it? If so, see if this article applies:
SMB file server share access is unsuccessful through DNS CNAME alias
Basically there was a change in the security model of Windows 10. Windows 10 by default won't request a Kerberos ticket for a DNS alias, but Windows 7 will. The SMB server is basically saying since you're not using my actual name (as shown by the service ticket), I won't allow the connection. Create a new SPN using the name that the successful Windows 7 machines are connecting with, but in SPN form. For example, if a Windows 7 is using something like this:
\servername.domain.com\sharename
..then find that name of the AD computer object representing the host and add a secondary SPN to that AD object like so:
HOST/servername.domain.com

Windows 8.1 wcf communciation common algorithm exception

We encountered a strange problem with a piece of software that works already for 5 years. Recently we changed pc's and we're now developing on windows 8.1
The issue: We have a website that in the background connects to a wcf service that's using a certificate. Then we launch the website and try to logon.
First we found out that we had an exception:
The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:19:59.9910127'
A strange message because we had this immediatly so we didn't need to wait 20 minutes to timeout.
Because we needed to found out what exactly was going on we tried this setup on another pc with windows 8.1 Everything worked perfectly, the website didn't had any issues.
Then we decided to swap the connections and see if we could reproduce so we ended up like this:
My to collegae => ok
Collegae to my => ok
Collegae to itself => ok
My to myself => error
Then I tried to search for answers in the windows log books. In the system log book. I found that there where issues with the tls protocol.
Windows eventid 36888, Windows eventid 36874
Then we searched for issues around tls because of those 2 event id's but we couldn't find anything.
What's even more strange is that we have a thick client also locally installed on my machine that connects via the same wcf services and this one works also correctly. The thick client and website are written in C#.
I enabled the wcf trace for the web client connection.
I share this file via this link: wcf-log
When opened in the Microsoft Service Trace Viewer on the tab page Activity the last message contains the error.
The client and server cannot communicate, because they do not possess a common algorithm
After a lot of research it ended up to be TLS 1.2
As soon as this was disabled everything works like a charm.
Other tests that we did where
creating a project in .net 3.5 and an exact copy in .net 4.0
The result was that .net 3.5 worked like a charm and .net 4.0 failed like described above.
By this last test we searched the web again and found out a link that maybe could help us.
WCF .NET 4.0 doesn't work without TLS 1.0
The tool showed us that we had enabled everything but by reading the post we saw that we could have another issue because we also had sql server 2014 installed on this machine installed.
I really hope if someone has this issue he finds this post. This kept us busy for 3 days.

MobileFirst application not using deployed adapter, attempting to use development server adapter instead

I'm running MobileFirst 7.0 on a Liberty installation.
Having successfully deployed my application and adapter into the runtime, the preview, when run from the servers operations console, is apparently trying to communicate with the adapter from the development server rather than the one running on Liberty.
[/MaximoMobile/apps/services/api/PhyCount/common/query] failure. state: 404, response: undefined
The runtime on the server is not called MaximoMobile, that is just the name of the project within Eclipse. It shouldn't be being referenced at all outside of the local copy of Mobilefirst.
I've looked up documentation in instructing the application to use the deployment server rather than the development server using JNDI entries in the server.xml file (http://www-01.ibm.com/support/knowledgecenter/SSHSCD_6.3.0/com.ibm.worklight.deploy.doc/admin/t_using_JNDI_lookup_to_override_WL_properties.html), but I can't see anything incorrectly set, or anything even relating to the adapter.
I have managed to set the endpoint to /worklight as required using Eclipse, but it's still returning 404 and attempting to access a non-existent file.
Answering my own question for people who may later stumble upon this looking for an answer:
The preview on the server doesn't work in the same way as the local preview does, and any part of the interface that requires an adapter won't function.
If you need to test the connection to the server, deploying to a device will allow you to do so!