I have a Ghost site at https://msclouddeveloper.com
However, the navigation links point to an azurewebsites.net address. But in the Ghost CMS the correct custom domain is shown (msclouddeveloper.com).
The websiteUrl appsetting is also set correctly.
What could be wrong? I've already restarted the app service.
Don't know if I missed this when reading the setup guide for custom domains, but you need to add two AppSettings:
websiteUrl http://www.msclouddeveloper.com
websiteUrlSSL https://www.msclouddeveloper.com
Then restart the App service.
What could also be an issue is the environment setup you have enabled. See this documentation for more info https://docs.ghost.org/docs/config
For custom domain SSL links to work you need to have the production environment enabled. You set this in the file iis-node.yaml I believe. But it was already correct in my case.
Related
Can someone help me in resolving Qualy's issue?
After Qualys scan, there is an issue that says to add the HTTP Only flag. I have set the HTTP Only flag in web.config of Asp.Net Application but it doesn't resolve. We are using Azure Active Directory (single Sign-On) authentication.
Don't know where I can set the flag to true. Moreover, in some blogs, they mentioned modifying NuGet packages.
I have attached the screenshot. please refer to it. Thanks in advance.
Flags are: wlidperf, ESTSAUTHLIGHT, brcap, ch, clrc
You can change the settings related to HTTPS Only option under the following root inside your Azure Dashboard:
Settings - Custom Domains - HTTPS Only
However, you have to checkup with your security options and configurations, because this can engender security related problems later down the road.
I have 2 frontend interfaces for my firebase project (both housed in the same firebase app in the backend). One is web and one is for iOS.
I'm trying to create passwordless sign-in functionality for the iOS app and have gone through all setup guides regarding setting up dynamic links, custom domains etc.
I have gotten to the point where both the web and iOS apps can both send the email successfully, however the root domain changes between the emails sent from each platform. An example is below:
Web App: Sends login email via firebase.auth().sendSignInLinkToEmail and the resulting root domain in the email is https://app.domainname.com (this is correct and is what is set up as a whitelisted domain/dynamic link domain in firebase)
iOS App: Using the same function, the resulting root domain is https://domainname.com (incorrect). This results in the link going to the non-firebase, generic website and breaking the flow.
If I add the app subdomain back to the link generated by the iOS email, the dynamic link does then work, so the issue seems to be isolated to this root domain change specifically.
Upon further investigation, the issue seems to be related to the action code settings.
When the iOS.bundleId property is set, or handleCodeInApp is true, the incorrect root domain is used. This is true for either the web app or the iOS app.
I have done a project find on domainname.com in both projects (my iOS app is an ejected expo app so the search included Xcode files for this one) and can't find any instance of the subdomain being missing in either codebase (or the backend codebase for that matter) and am therefore at a loss.
I've looked throughout my firebase settings and can't find any instance of the incorrect one appearing, but am unaware of a search functionality on the platform to be certain. The Action URL (%LINK%) setting in Authentication->Templates appears to be the correct URL.
I am hoping to get to the point where irrespective of the action code settings, the same, correct root domain is used. I assume this is a configuration issue but am at a total loss about how to resolve it, so any help would be appreciated.
For reference, the action code settings in use are below:
var actionCodeSettings = {
url: 'https://app.domainname.com',
iOS: {
bundleId: 'com.domainname.app'
},
handleCodeInApp: true
}
Thanks!
In case anyone finds this in the future, it turned out for me that the issue was due to a combination of an undocumented lack of support for custom domains in dynamic links in react-native-firebase, alongside the fact that the library will only send the email links using the first selected domain in your Firebase Dynamic Links settings.
At the time of writing, the solution was to simply delete all other domains from my Dynamic Links settings, leaving only PROJECTNAME.page.link, so that this was the one that got used by the library. From there everything worked as expected.
I currently develop Drupal web sites using its multi-site feature that allows me to have a single code base and support multiple distinct settings per each site.
I set up a dev server and I was quite happy with my arrangement of domains like example.com.local (not that happy because I had to perform a small conversion before entering production, but still quite happy) and the thing used to work well. Too bad I recently started to work at places outside the LAN in which my dev server resides--mostly at clients' places where I need to demo their sites. First of all I set up a dyndns.org account and the server is accessible through the Internet.
Unfortunately the whole domain-based multi-site ungracefully fell down, since I'm now accessing the server via myservername.dyndns.org and Drupal's algorithm takes the domain name into account, so I'm forced to use at least the TLD as part of the directory name (namely sites/local.example.com). So I decided to switch to directory-based multi-site, and now I'm able to access my server from inside the LAN using myservername.local/example.com (having renamed the sites/ subdirectories accordingly). You should easily see why this is suboptimal, since when I browse to myservername.dyndns.org/example.com Drupal looks for sites/org.example.com. I temporarily ended up making a link from sites/org.example.com to sites/local.example.com but again, this does not scale well If and when I'll have to drop dyndns.org for, say, dev.mycorporatesite.com...
Is there any other possibility? I have full access to the server, I can change Apache2's configs, .htaccess and all the stuff.
I would recommend against referencing drupal multisites in folders but instead would set up your server to have a fixed domain name and each site in a subdomain.
So your dev server is at mydevserver.com
and then each site could be
client1.mydevserver.com
client2.mydevserver.com
etc.
If you also at the same time as creating these, you move the files folder from the default to whatever the live site will be i.e.
sites/livesite.com/files
Then when you have to go live, all the references will be correct (if you are drupal 7 this might not be an issue)
Is there a way to display custom errors on specific host(s) (eg: www.example.com) and display vanilla errors on others (eg: beta.example.com)?
I'm thinking along the lines of configuration syntax that can be added to the customErrors section of the web.config.
It's actually for MVC 3, if that makes any difference.
The sites are hosted on separate servers. http://beta.yogaloft.co.uk/ is built and deployed automatically by appharbor and promoted to http://www.yogaloft.co.uk/ whenever it's ready for the wild.
what i would do is use customized HandleErrorAttribute to detect the request and show the custom error on the www.example.com ?
basically, extend the HandleErrorAttribute ( HandleCustomErrorAttribute : HandleErrorAttribute )and put the logic to detect if the request is coming from example.com and if so show a specified view.
I have not tried it this way, but shouldnt be impossible.
If this hosts are set on the same directory, you can't.
All you can do - use the customErrors="RemoteOnly" setting and beta test locally.
You really should use two different sites for the production and testing.
We have a web site in the domain, let's name: http://website.com. It is necessary to implement same look-and-feel on another web site (https://custom.website.com). As we can see, the 2nd is in the sub-domain of the 1st one, but it is secured (it uses https).
To achieve same look-and-feel same DLLs are used in both web sites. These DLLs contain functionality for menus, JavaScripts, etc). But the 2nd web-site uses images and some css files from the 1st one. For example, in order to display "Logo.png" instead of usual "~/Images/Logo.png" the following path to file is rendered into HTML: "http://website.com/Images/Logo.png"
All stuff was done on the local environment, and work perfect (http://localhost/ referred to http://website.com).
BUT, when web-site was deployed to 'real' (development) environment we got surprise: IE notifies:
webpage contains content that will not be delivered using a secure HTTPS connection
I see option to resolve an issue: we could include images into secured web site and use them locally, but in this case we will need to do redeployment if something changed on the main web site.
Question: is there any workaround, how from secured web site we could use images that are located on the non-secured.
Thanks. Any thoughts are welcome.
P.S. I am using ASP.NET 3.5, web sites are hosted under Windows 2008
You need to host your images, CSS and scripts (more generally, whatever is loaded from the webpage) on your HTTPS site too to avoid mixed-content.
Depending on the level of security and isolation you could set up a shared virtual directory for the two websites that point to the same physical location.
Example, create a directory at C:\inetpub\shared-static and create a virtual directory /static under each website pointing to C:\inetpub\shared-static. From there both websites can refer to the image like ~/static/logo.png as necessary for shared content. When the directory has a new file (or replaced file) placed in it, both websites will refer to the same file.
If you can enable support of https on the main web site, you could use https for the image urls instead of http.
Alternative as others have suggested is to sync images / or used a shared location when serving them.
I see workaround:
on the 2nd web-site implement functionality that will check (once per day or per hour) if own images are the latest and update them when necessary...
That is a some work, but with such solution web site will be easier to support.
If you see a better option, please let me know.
Thanks.