The Spartacus seems to not update the base site in some scenarios when it is loaded with SSR. This happens mostly when we had just deployed the app or, in some cases, when you navigate from one site to another.
To reproduce this issue, you have to configure at least two sites on SAP Commerce and it's recommended to edit the "hosts" file in the local machine, to access the production-like URL. For example:
127.0.0.1 yourFirstDomain.local
127.0.0.1 yourSecondDomain.local
Then, run the Spartacus with SSR, access one of the sites, and edit the URL to access the second one.
To test to see if the base site was updated, I subscribed to the Spartacus base site service and logged the base site Id. When I access the first site, it logs the correct Id. But when I access the second site, editing the URL, the log does not occur and, although the URL changes correctly, the site (data, look, and feel) doesn't change and remains as the first one.
Is this a bug or something that could be configured?
Related
I transferred my prestashop site to another host and domain and now im getting "redirected to many time" error.
This page isn’t working
www.yoursite.com redirected you too many times.
Try clearing your cookies.
ERR_TOO_MANY_REDIRECTS
If you has move from one domain name to another, as first step you need clear cookies in your browser, and clear cache also, then you need update the domain name in the SEO & URLs tab, inside the Advanced parameters.
If you are getting issued by access to the Back Office, you can change this also directly in your database in the table ps_shop_url, you need update domain and domain_ssl.
What are the best practices (and how to go about doing it) to support offline mode when using html5 history api for url rewrites?
For example, (hypothetically) I have a PWA SPA application at https://abc.xyz which has internationalization built in. So when I visit this link, the Vue router (which ideally could be any framework - vue, react, angular etc.) redirect me to https://abc.xyz/en.
This works perfectly when I am online (ofcourse, the webserver is also handling this redirect so that app works even if you directly visit the said link).
However, its a different story when I am offline. The service worker caches all resources correctly so when I visit the URL https://abc.xyz everything loads up as expected. However, now if I manually type the URL to https://abc.xyz/en, the app fails to load up.
Any pointers on how to achieve this?
Link to same question in github: https://github.com/vuejs-templates/pwa/issues/188
Yes, this is possible quite trivially with Service Workers. All you have to do is to configure the navigateFallback property of sw-precache properly. It has to point to the cached asset you want the service worker to fetch if it encounters a cache miss.
In the template you posted, you should be good to go if you configure your SWPrecache Webpack Plugin as follows:
new SWPrecacheWebpackPlugin({
...
navigateFallback: '/index.html'
...
})
Again, it is absolutely mandatory that the thing you put inside navigateFallback is cached by the Service Worker already, otherwise this will fail silently.
You can verify if everything was configured correctly by checking two things in your webpack generated service-worker.js:
the precacheConfig Array contains ['/index.html', ...]
in the fetch interceptor of the service worker (at the bottom of the file), the variable navigateFallback is set to the value you configured
If your final App is hosted in a subdirectory, for example when hosting it on Github pages, you also have to configure the stripPrefix and replacePrefix Options correctly.
I'm developing a database backed web-app. I will be providing the same basic services to several branches of the same company.
Right now I have an Apache server with virtual servers and a resource server for reporting.
branch1.mycompany.com
branch2.mycompany.com
resources.mycompany.com
So basically when I call resources from the site I pass the site as a parameter.
branch1.mycompany.com -> resources.mycompany.com?branch=1¶meter=1
branch2.mycompany.com -> resources.mycompany.com?branch=2¶meter=1
Even with two branches there is a problem trying to keep up with updating both sites and now, I'm going to be implementing this scheme for seven sites.
So my question is this: Is there a way I can make a IIS or TomEE web-app with the following features?
I want to still allow each branch to access trough its URL
Even when there are 7 URLs; all of them will be pointing to the same web-app
Depending on the URL, is there a way the site parameter can be inferred or calculated so I can call the right resource or web service?
The user should never realize they are accessing a common web-app. (i.e. should not be redirected to web-app.mycompany.com?site=1.)
Tomcat (so tomee) has now a rewrite valve which is close to httpd mod_rewrite, this can surely solve that smoothly. I assume IIS has it as well but don't know it that much. Trick is to reverse proxy the requests.
I had error when access SharePoint sites out of the server , as when I
try to add new document or did any action this error displayed although
it worked well in SharePoint server
I think Yevgeniy made a good suggestion.
I assume you mean by 'outside' the server, users are trying to view the page on a different URL? If so, it might be the URLs to access the site 'outside SharePoint' are not configured correctly.
I would suggest a few things to start with:
When you say it works 'in SharePoint server' does this mean that the whole site is accessible, with no problems? But using a different URL (i.e. host header?), fails - for just this one page with the list or the whole site?
Check you have Alternate Access Mappings configured correctly as suggested above - check that the URL is setup correctly in any AAM zones defined, and that the authentication (e.g. Anonymous, Forms whatever required) is also setup too. This is all done in Central Administration.
If AAM setup correctly, check if you have any firewall or other network security that may block access to the site (again, assuming users are routed externally?)
Does the problem page or list (or the subsite it is within) have any unique security permissions?
You can check for the site via Site Actions | Site Permissions - if it does not have unique permissions, you will see a 'This Web site inherits permissions from its parent.' message.
If the List has unique permissions, you can check by going to the list page, and clicking 'Library Permissions' on the Library grouping on the Library Tools section of the ribbon.
I have built a cookie consent module that is used on many sites, all using the same server architecture, on the same cluster. For the visitors of these sites it is possible to administer their cookie settings (eg. no advertising cookies, but allow analytics cookes) on a central domain that keeps track of the user preferences (and sites that are visited).
When they change their settings, all sites that the visitor has been to that are using my module (kept in cookie) are contacted by loading it with a parameter in hidden iframes. I tried the same with images.
On these sites a rewrite rule is in place that detects that parameter and then retracts the cookie (set the date in the past) and redirects to a page on the module site (or an image on the module site).
This scheme is working in all browsers, except IE, as it needs a P3P (Probably the reason why it is not working for images is similar).
I also tried loading a non-existent image on the source domain (that is, the domain that is using the module) through an image tag, obviously resulting in a 404. This works on all browsers, except Safari, which doesn't set cookies on 404's (at least, that is my conclusion).
My question is, how would it be possible to retract the cookie consent cookie on the connected domains, given that all I can change are the rewrite rules?
I hope that I have explained the problem well enough for you guys to give an answer, and that a solution is possible...
I am still not able to resolve this question, but when looked at it the other way around there is a solution. Using JSONP (for an example, see: Basic example of using .ajax() with JSONP?), the client domain can load information from the master server and compare that to local information.
Based on that, the client site can retract the cookie (or even replace it) and force a reload which will trigger the rewrite rules...
A drawback of this solution is that it will hit the server for every pageview, and in my case, that's a real problem. Only testing that every x minutes or so (by setting a temporary cookie) would provide a solution.
Another, even more simple solution would be to expire all the cookies on the client site every x hour. This will force a revisit of the main domain as well.