Hi, Everyone.
With Spartacus 4.0 onwards, the canonical URL is configured to be default as below. However, the canonical URL for PDP page has local IP address in quality and production environment. The other pages have the domain name as expected. Any help to resolve this
pageMeta: { canonicalUrl: { forceHttps: true, forceWww: false, removeQueryParams: true, forceTrailingSlash: true } }
Setting it manually on PDP controller also didn't help.
this.pageMetaLinkService.setCanonicalLink(this.winRef.location.href);
Any help to resolve this will be appreciated. Thanks!
Related
I tried to fetch the current theme of my NetSuite website and edit it and check it locally, but didn't find the local link.
I didn't get this part, explained on NetSuite Help Center:
To view your customized theme in a browser, navigate to the local version of the application using one of the following URLs:
http://<DOMAIN_NAME>/c.<ACCOUNT_ID>/<SSP_APPLICATION>/shopping-local.ssp
I tried the below links but not working:
http://localhost:7777/c.1234567/scs/shopping-local.ssp
https://domain-name.com/c.1234567/scs/shopping-local.ssp (I try it with my organization id and company domain name)
At localhost:7777 nothing loaded up and at the second link site loaded but without my changes in header.tpl or footer.tpl module files.
The development mode piggybacks off of the live site. Basically the live site has some special .ssp pages that, instead of loading resources from Netsuite, proxy to a service on your local host.
For example if you were running a site at http://www.mynsbasedsite.com
on site that has url root /kilimanjaro then to see your development changes you'd enter the url:
http://www.mynsbasedsite.com/c.<ACCOUNT_ID>/kilimanjaro/shopping-local.ssp
Are you running the local dev service? e.g.
gulp local
If you start that up in the last few lines you should see one or both of these:
+- Local http server available at: http://localhost:7777/
+- Local https server available at: https://localhost:7778/
If you don't see the https reference it's because you haven't created a self signed cert for your local server. Most modern browsers need some coercion to load the either of those.
e.g. when I am testing with Chrome I do the following:
open the staging url and get a blank page
open dev tools and go to the network tab
find checkout.js in red with a failed status
right click and choose 'open in new tab'
see the page warning, click 'Advanced' and click 'Proceed to localhost (unsafe)'
go back to the original tab and refresh.
the versions of SuiteCommerce I'm familiar with use Express under the hood for the local server so any ssl tutorial on Express should include a section on using openssl to generate your key and cert. Once you've created them they go in the root folder of your project and you reference them in the taskConfig section that starts like:
"tasksConfig": {
"local": {
"http": {
"port": 7777
},
"https": {
"port": 7778,
"key": "./key.pem",
"cert": "./cert.pem"
},
"lessSourcemap": false,
"jsRequire": true
},
"configuration": {
After all that navigate to your live site.
I have this application that I just installed a SSL certificate for. Yest I tried to redirect the users to use only the HTTPS://url.com. and prevent them from using the http://url.com site. However because I lack understanding the regular expressions to define the Pattern and the condition and unfortunately, I could not find a guide with some example of how to define those rules. I would like a concrete example of how to set this up https://{HTTP_HOST}{REQUEST_URI}.
Ensure you have the URL Rewrite feature added. In IIS manager configure the following in the URL rewrite section.
Create inbound rule (Blank Rule)
Requested URL : Matches the pattern
Using: Wildcards
Pattern: *
Conditions
Input: {HTTPS}
Type: Matches the pattern
Pattern: off
Action
Action Type: Redirect
Redirect URL: https://{HTTP_HOST}{REQUEST_URI}
Append Query String Checked
Redirect type: Found (302)
Once you have done this. Create a condition...
Right click your new rule
Conditions -> Add+
Condition Input : {QUERY_STRING}
Matches the Pattern
Pattern: off
Essentially it should look like this:
All traffic using a http request will be automatically redirected to the https port.
I think I've found a solution without url rewrite. In IIS, right click on the website, choose "Manage web site - Advanced settings", expand "Behaviour", expand "HSTS" and set to "True" the properties "Enabled" and "RedirectHttpToHttps".
Update:
As #jonasfh pointed out, you need anyway to have bindings both to http and https, because only the successful requests to http are redirected to https. So, if the request to http isn't successful (because http binding is not present) the redirect to https doesn't happen. Thank you.
Update2: just wanted to add that after the settings a site restart from IIS is needed.
My method from Global.asax
protected void Application_BeginRequest()
{
#if !DEBUG
if (!Context.Request.IsSecureConnection)
{
if (Context.Request.Url.ToString().Contains(".well-known")) return;
Response.StatusCode = 301;
Response.RedirectPermanent(Context.Request.Url.ToString().Replace("http:", "https:"));
}
#endif
}
I followed instructions to set up swagger documentation for my existing node API using swagger-jsdoc.
The swagger.json is being served correctly and I added a path to it in the url parameter of the SwaggerUiBundle in index.html like this:
const ui = SwaggerUIBundle({
url: "https://my.domain:5292/swagger.json",
dom_id: '#swagger-ui',
presets: [
SwaggerUIBundle.presets.apis,
SwaggerUIStandalonePreset
],
plugins: [
SwaggerUIBundle.plugins.DownloadUrl
],
layout: "StandaloneLayout" })
However, the first thing it tries to do when opening the page in the browser is showing the default http://petstore.swagger.io/v2/swagger.json instead of my swagger.json. It actually fails to do so because I'm serving the page through https and the petstore is not https but that's a different matter...
Inputing my address to the swagger.json manually into the form on the page works as expected. It shows the API page correctly and validates it. However, I don't want to always re-enter the address there and would like to have it as a default.
Swagger UI 3.0.9 had a bug where it ignored the url parameter and always opened Petstore.
It was fixed in 3.0.10.
I had been having this issue lately when deploying using docker. Tried everything from changing all instance of petstore to my own api json docs but to no avail.
Finally I found out about API_URL environment variable, set it to my api docs in DockerFile and voila!
Took me two days but it was great to see it finally working.
You can disabled default url by adding below configuration in application.property file
springdoc.swagger-ui.disable-swagger-default-url=true
I am having issues after I changed the subdomain of my app, it was working the day before but now it doesn't it shows me the message
OneSignal: Could not load iFrame with URL
https://acacito.onesignal.com/webPushIframe. Please check that your
'subdomainName' matches that on your OneSignal Chrome platform
settings.
<script>
var OneSignal = window.OneSignal || [];
var OneSignal = window.OneSignal || [];
OneSignal.push(["init", {
appId: "MyAppID", // copied correctly the UUID
autoRegister: false, /* Set to true to automatically prompt visitors */
subdomainName: 'acacito',
httpPermissionRequest: {
enable: true
},
notifyButton: {
enable: true /* Set to false to hide */
}
}]);
</script>
I have been trying to make it work deleting cookies or any data related that could be stored in the browser and it doesn't work. Also reloading with Ctr+Shift+r, not sure what happens.
At the time of this writing, this error can occur if:
The Site URL in your onesignal.com dashboard settings does not begin with the same URL you're using to access your site.
For example, if your dashboard platform setting's Site URL is http://my-site.com, you have to access your site beginning with the URL http://my-site.com. You can access http://my-site.com/page1, and you can access http://my-site.com/folder/page2, but you have to begin with http://my-site.com. Technically, the Site URL is the origin your OneSignal configuration is allowed to run under, and OneSignal doesn't allow any other site origin from initializing OneSignal with the same subdomain.
For more complicated cases:
If you're developing locally on http://localhost:8181, your Site URL should also be http://localhost:8181 (with the port number).
If you have an alias defined in your hosts file, you still have to use the origin specified in your Site URL. The OneSignal web SDK looks at what's on the address bar and compares it to what's in the Site URL textbox.
The value for subdomainName (in this case acacito) does not match the value you chose in your onesignal.com dashboard settings for Chrome web push.
Just be sure to use the same value.
I am trying to develop a chrome extension that would set the "host" header on certain requests. But the documentation is contradicting as to if the "host" header can be modified or not.
Both of these issues indicate that a) it should not be possible and b) it is impossible
https://code.google.com/p/chromium/issues/detail?id=154900
https://code.google.com/p/chromium/issues/detail?id=158073
Yet multiple extensions in the gallery state they do modify the "host" header.
e.g.
https://chrome.google.com/webstore/detail/header-hacker/phnffahgegfkcobeaapbenpmdnkifigc?hl=en
https://chrome.google.com/webstore/detail/change-http-request-heade/ppmibgfeefcglejjlpeihfdimbkfbbnm
Is it possible to modify the "host" header in the windows version of chrome, and if so how?
Background: I want to be able to test load balanced web instances hitting each host directly via ip address. The "hosts" file is to cumbersome for a large number of hosts. At the moment I use curl to pass the modified "host" header, but I really need the solution in the browser and available for others.
#kzahel was right, and the note about redirection was spot on, here is my basic working code.
chrome.webRequest.onBeforeSendHeaders.addListener(function (details) {
if (details.url.indexOf('toast.txt') <= -1)
return;
details.requestHeaders.push({
name: 'Host',
value: 'testhost:80'
});
return { requestHeaders: details.requestHeaders };
}, {
urls: ['http://*/*']
}, ['requestHeaders', 'blocking']);
chrome.webRequest.onBeforeRequest.addListener(function (details) {
if (details.url.indexOf('sauce') <= -1)
return;
var url = 'http://127.0.0.1/toast.txt';
return { redirectUrl: url };
}, {
urls: ['http://*/*']
}, ['blocking']);
Admittedly a slightly odd example but it goes like this.
My local IIS has a site created that points to a folder that has a file "toast.txt", which is bound to "testhost".
Windows can no way of knowing about "testhost" e.g. cannot ping it.
With the extension running.
Enter the address http://testhost/sauce
The extension notes the "sauce" in the "onBeforeRequest" method and redirects to "http://127.0.0.1/toast.txt" which in turn is picked up on by the "onBeforeSendHeaders" method where the "Host" header is added containing "testhost:80". All this occurs before the request leaves Chrome.
Now IIS receives the request "/toast.txt" that by itself would result in a 404, but because the "Host" header is set it pushes the request to the new website that is bound to "testhost" which then returns the "toast.txt" file.
Phew!
It looks like you shouldn't have difficulty doing this. Use onBeforeRequest
onBeforeRequest: Fires when a request is about to occur. This event is sent before any TCP connection is made and can be used to cancel or redirect requests.
Since this is triggered before any connection to the server is made, you should be able to modify the host header then [edit: if host header is not available, then use a redirect]. Make sure you have the "requestHeaders" permission in the manifest or else you won't see the request headers at all.