I have a streamlit web application. It is hosted on a vps server, combined and configured with nginx. Additionally, I received and configured access by domain name, received a ssl certificate.
I would like to place this application in Google search engines. So that when you enter a domain name into Google, it appears in the search results. I looked at the google documentation on how to do this. Actually there are two ways:
Creation of a special html page in the root directory
Adding a meta line on the main page of the application.
It seems to be nothing complicated, but how can this be done if I use streamlit as the basis of the web application? Can you give an example of what needs to be done to confirm the right to host the site?
Related
I just created a webform that is hosted in my Azure subscription. I set it up with authenication via my works Azure directory for authenticating users. In debug this works fine and I am able to login with my work credentials and then view the website via local host.
I have published this to my Azure and it says it is running and working fine. So when I try to connect to the website it continuously redirects me to the localhost resulting in an error.
I have checked the web config.
Here is the google network chain of events when it occurs.
I am really lost as to what is wrong and what I need to do to fix this so any help would be greatly appreciated. I'm sorry I can't offer more but I don't even know what is wrong to begin with or where to look. Is there some setting in Azure that I need to add the website too?
I have solved this issue. Since it was such a pain I will keep this up as I couldn't find any answers on this. It was actually quite simple.
You have two options. The one I did and which worked was changing the publish profile as below:
Add the domain where the authentication is occurring. So if you have your web app hosted by a different azure account that which is authenticating the users, use the one that is authenticating.
This will create two versions of your app on the site one for local host and one for the actual site.
The second option(I have not tried this but it should work) is to go to the Azure account where you are authenticating the users and go to applications and then configure. Change the APP URL from local host to the url you are trying to get to.
Here is an excellent link that explains how to do this clearly.
Click this link for detailed explanation
I also had this issue and took these steps to resolve
navigate to the app registration in AAD
Open the manifest
Change the ReplyUrl to the url of the app (e.g. http://appname.azurewebsites.net)
Then I got the error
Bad Request - Request Too Long HTTP Error 400. The size of the request headers is too long.
Next I cleared all cookies from the browser, and this changed the error to just
Bad Request
So I went back to that ReplyUrl and changed it to https://appname.azurewebsites.net/.auth/login/aad/callback and now it appears to work.
Note I also had to make sure I didn't have the site open in any other tabs before it started working
I had this issue when I switched an app from our company Azure over to a customer's Azure. In my case I'd forgotten to update the ida:ClientId, ida:AADInstance and ida:TenantId, which then meant that the value I'd set for ida:PostLogoutRedirectUri was ignored (I think) and instead my app redirected to localhost.
Once I changed those ida values to the values from the app settings and subscriptions settings on our customer's Azure it all worked as expected.
It took a while to track down all the values in Azure portal as they are all called something different, or aren't named at all:
ClientId can be found at Azure Active Directory > App Registrations > YourAppName. It's called 'Application ID' in Azure
Domain can be found on Azure Active Directory > Overview. It's currently in the top left in the format somename.onmicrosoft.com
TenantId this is the Azure AD instance ID, get that from Azure Active Directory > Properties and then it's called 'Directory ID'
I spent a lot of time trying to work out where the localhost port that was being redirected to was in the code, but it simply isn't there as far as I can see, so I have no idea how Azure was choosing what localhost address to redirect to!
You need to set another parameter in configuration that is replyUrl and assign to your web app, other wise it takes the url from which it was originated.
I was able to fix this by changing my Startup.Auth.cs file redirectUri from "https://localhost:44316/" to https://myapp.com/
Currently my application url is xyz.azurewebsites.net. I have to host that application to another domain like www.xyz.com. I have company's domain and I have to host from xyz.azurewebsite.net to company's domain.
I don't know how to host from azurewebsite.net to another domain.
Please suggest me proper steps.
Thanks!
I'd suggest you configure a custom domain name for your web site. Since you already have company's domain as the custom domian. You just need to do below two basic steps:
1.Create DNS records that map the domain to your Azure web app.
2.Add the domain name inside the Azure Portal.
Note: Setting a custom domain name is only available for the Shared, Basic and Standard modes for Web Apps. Before switching a web app from the Free mode to the Shared, Basic or Standard mode, you must first remove spending caps in place for your Web Apps subscription.
For detailed information, please refer to this MS article.
I'm working on creating a report page for an ASP.NET project, the url to that page is
'localhost/reports'
But for some reason, the SQL Server reporting page is turned on and now there is a url conflict.
So my url now redirects me to the following url:
'localhost/Reports/Pages/Folder.aspx'
It seems the behavior of '/reports' is overwritten by the SQL Report Service site. I would like to know how to turn on/off the db service(report browsing) site manually or by DDL change
You can turn of the entire reporting service in the SQL Server Configuration Manager or you can go to the Reporting Services Configuration Manager and change the Report Manager URL to point to a different location. The default is /Reports.
If you look under "Internet Information Services (IIS) Management", I usually just search for it from start menu, you will see an app pool for reporting services/SSRS with a Reports entry under it. You will probably also see an entry under Default Website. Unfortunately different versions of IIS manager will look different. If you find the "Reports" entry under the Websites/Sites entry, and right click you may have a Properties or Manage Virtual Directory option. Basically IIS handles routing requests to different web applications. So each web application that wants to handle a certain base URL must be configured here. Often times this is done without your knowledge through a deployment or install process, but for more complex setups you might modify IIS directly.
Basically you have a situation where your app and SSRS both have a path in IIS that responds to /reports/. As JodyT answered, the correct solution is to modify the Reporting Manager URL(which likely in turn modifies IIS). I wouldn't be surprised if you had to reboot or run IISReset to get this change picked up. It's hard to say sometimes, but hopefully not.
Change Configuration for SSRS.
Follow these Step:
Open Reporting Services Configuration Manager
Click on Reporting Manager URL
In virtual Directory Change Folder Name 'Reports' to 'Reports2'
Click Apply
Now Check website
I have two web site that are 99% similar. They share all of the same pages except the difference being that the logos change, a few of the links change, and the products that show up on either web site are flagged to show up on either or, or both. They use the same database.
I have written a utility method that essentially injects a where clause into any database access code I write throughout the app to determine which products to display depending on the current URL.
Problem: Website B gives the user a warning message that the site they are trying to go to is in fact Website A. I've read that the SSL cert needs a distinct IP.
Right now how I have everything set up is very clean on a maintenance perspective. I can update files in one place. Any suggestions on how to make the SSL behave, or am I looking at seperate IP's for the hosting(I really don't want to have to do this)?
If the latter, what do you suggest?
Site runs ASP.NET 4.0. Precompiled DLL.
UPDATE: Thanks to #GregS comment
If the sites share the same domain you can use a wildcard certificate
site1 - site1.somedomain.com
site2 - site2.somedomain.com
Otherwise you will need to get a UCC (United communications certificate) that will be for both domains.
You will need to configure IIS 7 from the command line because the GUI doesn't support setting different host headers for the same certificate. This tutorial shows how it can be done.
I setup another website in IIS that points to the same files as the first web site, got another SSL cert for the new site.
I would like to create a sandbox area on my hosting provider that only the client can see. For example the production website would be at www.domain.com. However, would it be possible to create a sandbox version of the website at www.domain.com/sandbox and only provide access to the client?
If so, what is the best method? Do I manually have to create a login page etc in the sandbox folder? Or, can I publish the test website in the sandbox area and restrict access through my hosting provider?
Generally a sandbox/staging/test version of your production site would be a complete duplicate of your production deployment, not just the login page.
You'd have a separate copy of the application and the database, and then serve it via another hostname/IP address or on an entirely different machine.
For instance, you could have www.domain.com and test.domain.com, each with the own isolated version of the software. This way your client can play as much as they want in the sandbox without fear of damaging the production environment.
To restrict access you could use access control lists in IIS to restrict the sandbox to a specific ip address (or range), or enable basic support on it with a username/password required security.