My VB.Net Windows form desktop application needs to complete an OAuth2 authorization to access online data from Intuit (QuickBooks Online). I am able to successfully (1) obtain the URL of the authorization web page, (2) redirect the user to that page, (3) receive the authorization code in the HTTP request from the URL redirect using HPPTListener when the URL is "localhost" and finally (4) retrieve the access token.
However, to use this app in production, the redirect URL cannot be "localhost" and must be https, not http. When I set the HTTPListener to monitor an https URL (e.g. https://www.stinsonsolutions.com, my web site), it does not receive any HTTP request like it does when set to monitor "localhost".
I saw one post suggesting opening a certain port in my Firewall, But since this app will be deployed to other users, that solution would not work. Is it not possible to listen to an https URL outside my app with HTTPListener, or am I missing a step? If it is not possible with HTTPListener, what can I use in my desktop application to receive the HTTP request sent to a https redirect URL?
Thanks.
Related
I am working on a web application that is hosted in the internet, but shall be able to use a REST API provided by a local HTTP-printserver.
The problem is, that when the application is accessed via HTTPS, all my XmlHttpRequest to the local HTTP-printserver are blocked (because of security mechanisms of the browser).
Therefore my "solution" is to use plain HTTP for the web application.
However, whenever I open the site in my browser - explicitly with http (e.g. http://mysite.de/app/index.html) the browser sends an "Upgrade-Insecure-Requests" which is accepted by the webserver and they switch over to HTTPS.
Is there a way how to deny/reject the upgrade to HTTPS?
Ideally by .htaccess
Ideally only for index.html in the app folder
I currently have an API setup at
http://public_static_IP:5000/api/parameters (POST requests).
I have bought a domain from NameCheap and hosted in GoDaddy, also added SSL from Cloudflare.
I have created a URL Redirect of a subdomain(http://www.web.domain.com) to http://public_static_IP:5000, which is a webpage and it is working fine.
I did the same with another subdomain(http://www.api.domain.com) to API endpoint which is an only POST request, so when I add all parameters and send a post request to this subdomain it is giving Method not allowed.
This is very important for us as users will always be using this API service and we don't want any downtime(sometimes ISP will be down), if ISP is down we want to temporarily route to some cloud service(AWS or Google Cloud) without asking users to change their base URL always.
Thanks in advance.
I'm currently playing around with SignalR and websockets. From my research, it seems, as websockets do not support custom headers, there's basically only two ways to authenticate a websocket connection during token based authentication.
1) Passing the token in the query string
2) Storing the token in a cookie which then gets passed to the server when WithCredentials is set to true
The first method isn't great practice - even through websocket communication is encrypted, query strings may be logged by servers etc.
The second method I have got working on my local machine but it doesn't work once deployed because my client and server reside on different domains. So basically, I have an Angular site that has one domain (eg. client.com) and a WebAPI site that alls CORS with a completely different domain (eg. server.com). On my browser, if I'm on client.com, I cannot set a cookie that gets sent to server.com on a request.
What is a good way to authenticate websockets when client and server sit on different domains?
The WebSocket Protocol specification doesn't specify any particular way for authentication. You need to perform the authentication during the handshake phase and for that you can use any HTTP authentication mechanism like Basic, Digest, etc.
Further you could look into JWT token based authentication. Angular app can store the token in local storage and send it as a Transport header during the handshake request to the server. If the token is invalid, server can terminate the WebSocket connection upgrade request and the Angular app can re-direct the user to login page.
I have a web application with servlets and jsps running on tomcat. I have enabled the tomcat to use https for all the users/visitors. I want to know if there is a way I can disable the https for users who are not logged in and are just browsing through the application.
Thank you
If you are searching by a Tomcat setting to do that, the answer is no. If you open a port https/ssl security, you opened it for everyone (the only exception is if you intent to use client authentication using ssl client certificates, that a guess is not the case here).
However, you can check if the user is accessing using https (using HttpSerlvetRequest.isSecure()) and send him back to http with a redirect, or change all page links to starts with 'http', if he is not logged in. That will make sure that any link the user clicks will send him back to http.
Is there anything wrong with configuring a webserver to map SSL traffic (port 443) to the same document root as normal traffic (port 80)?
Using the same document root for both http and https means you need to implement the following:
On each page that needs to be secure, there needs to be some application code that redirects the user to the https version if they somehow got to the http version (or to rediect the user to the login page if they have no session).
The login page always needs to redirect to the https version.
For pages that are accessible via both http and https, you need to set a canonical URL to ensure it doesn't appear like you have duplicate content.
Is there a better way to configure encryption of user account pages? Is there a best practice to separate website into HTTP and HTTPS sections?
It's not necessarily wrong to do this, but as your points 1..3 show, it introduces complications. It seems to me that setting up a separate document root might be a lot simpler than working around the complications.
In Internet Information Server 7.X you can define a "secure path" which is require to access with HTTPS and you can redirect the user to a user-friendly error page.
Maybe this can be a good solution to mix the document root and keep parts of the application secured.
Redirecting http automatically to https allows for man-in-the-middle attacks and is therefore not recommended. A man-in-the-middle could manipulate your HTTP traffic to send you to a malicious HTTPS site that resembles your HTTPS content.