I have several calendar stacks in 2 different sites on 2 different servers (one in the US and one in EU) They all stopped working a couple of days ago.
I’m using Foundation6, but after testing with UIkit3 and a plain “nothing” option noting loads still. Dod something change in the JS of RW or did all the frameworks have an update that kill calendar loading ?
I don’t know but haven’t heard anything from anyone else.
What calendar stacks are you using?
Do you have a URL to one of the pages?
The public events are available and publish to other systems fine. Only RW seems to choke on them 
Looks like you have a bunch of 503 errors on the calendars used by the Kalendar Stack.
Looks like the URL is kind of strange
Has two `https protocols. I don’t own kalendar so I know little about it.
I would doubt the frameworks had anything to do with the issue.
Not sure why you would think that two frameworks from two vendors would have broken the Kalendar stack. I know Kalendar stack is very popular so maybe someone else will chime in.
Are you not in a country that has GDPR? Just curious as I didn’t get a privacy warning and you have google analytics.
It would also be nice if in your stacks preferences you would switch on the Include Meta Tags option. It really doesn’t do a thing to hurt your site and makes it easier for people helping you.
1 Like
We had a similar issue some months ago. There’s a Heroku App deployed to avoid CORS problems, so all requests from the stack go to the to Heroku App, and then to the iCloud Calendar.
Good stuff. Thanks for all the great tips.
That Heroku “redirect” definitely is hijacking the url. I’ll see what to do about that.
I’m also using another calendar solution that has been working real well for years now, but is unsupported. (I just needed to load the upcoming event on a transparent background) They both quit at the same time so this app interference makes sense.
Verstuurd via een handig mobieltje.
Rather then “hijacking” the URL, If it’s a Cross-Origin Resource Sharing (CORS) issue I’d probably handled it by setting Access-Control-Allow-Origin HTTP header to allow the cross origin resources needed.
For example in Apache you could add the following to the htaccess
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin https://example.com/
</IfModule>
Just change the example.com to what you need.
1 Like
So this Heroku app should actually help? It almost looks like that actually is what’s blocking the requests. Whats weird about this is that it could only be:
- The host server installed something
- A RapidWeaver (or stack) changed something.
The rapid weaver part is most likely, because the same problem is happening on a US server and website as on a Dutch server and website…
Tried this but I may not understand the url that needs to be listed here. We have 9 calendar urls (that have been linked for 6 years this way as a side note), or is this teh folder url where the calendar stack is located?
The URL need is for any external domains to the domain you are using.
This tells the browser to allow code from any origin to access a resource
access-control-allow-origin: *
This tells the browser to allow requesting code from the origin developer.mozilla.org
access-control-allow-origin: https://developer.mozilla.org
You can add multiple access-control-allow-origin: one after the other.
It looks as though in the example URL you are trying to " hijacking the url’ with something you got from Heroku? I would remove that and try adding this:
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin: https://p24-calendars.icloud.com
</IfModule>
I doubt it’s anything to do with RapidWeaver by itself. The RapidWeaver application
alone, does nothing with http headers. Some stacks might. But you have said you have 9 calendars running on multiple servers with multiple websites and they all stoped working. If you didn’t change something and republish all of these sites, it wouldn’t have come from RW itself. Now I have no idea how that hijacking the URL is trying to work, it looks like it is using a domain of https://pure-springs-67256.herokuapp.com/?
It’s a lot of work for people to go through all your sources code to figure out what is going on when you have the meta tags turned off(NO reason to have them turned off). If you want further help with this PLEASE:
BTW, the “Stacks Meta Tags” was always checked - not sure what is going wrong there either. 
It’s not “hijacking”, that’s a simple “forwarding application”, deployed on Heroku to solve the mentioned CORS challenge. We had a similar problem here in the forums with another plugin some time ago.
Not everybody is able to modify the server settings of his hosting provider. That’s why this sort of forwarders are used from time to time. They simply accept all requests, the target url is attached to the request, forward the request to the final destination and return the result back to the requester, in our case the calendar stack.
No meta tags are there so probably wasn’t when you published the URL you gave above. You also are missing the <meta name="generator" content="RapidWeaver"> tag so perhaps you are running something that strips out meta tags?
Okay,
The errors that the URL given above have nothing to do with CORS. They are http 503 Service Unavailable.
The server that is responding with the 503’s is the https://pure-springs-67256.herokuapp.com.
That is the server that is supposed to forward the request correct? It’s the part that isn’t working. Forwarding requests like that should be a “last ditch effort” as you bring into play another point of failure not to mention the overhead of transmitting data from one URL to another simply to forward.
The great majority of users have access to the htaccess file. RapidWeaver even has an easy little htaccess file editor built into the publishing part.
https://pure-springs-67256.herokuapp.com/https://p24-calendars.icloud.com/published/2/MzgzNTAzMjUzODM1MDMyNdli1zQfYa9Vr5bBlos4nm7tUrqQZrEnBB1OzTsQTuLE5BZpH5Suw5MSTalXv-H_SB5ZF9XYP-2K_-cTDJTfneA
https://pure-springs-67256.herokuapp.com/https://p24-calendars.icloud.com/published/2/MzgzNTAzMjUzODM1MDMyNdli1zQfYa9Vr5bBlos4nm6VBxgqTAfirMwwp8-_aOmKUyMkfwR5XbtuTpAeNtBzKTW2uCfAWGQucqOcQqNwlK8
https://pure-springs-67256.herokuapp.com/https://p24-calendars.icloud.com/published/2/MzgzNTAzMjUzODM1MDMyNdli1zQfYa9Vr5bBlos4nm7Xlq-p8zIqWGuQyiluNob65urL_SjI2Yu4lCPDAR9_TgNUl4A8Dkmn6eynSZk883Y
https://pure-springs-67256.herokuapp.com/https://p24-calendars.icloud.com/published/2/AAAAAAAAAAAAAAAAAAAAAKt9XUf9bINNtWx7IxGa_4ZtXN7QonJSZpo0kbi9BFXzgCIUzwBcNaveoQDY4nie5kPf8YYyHVfrnfziQpXokaU
https://pure-springs-67256.herokuapp.com/https://p24-calendars.icloud.com/published/2/MzgzNTAzMjUzODM1MDMyNdli1zQfYa9Vr5bBlos4nm44oNzhambfXCzjoTCR0TbsTz7NXCTVzy8V6GN5FKW52JOPlF2eyBzyCdoN7Av65E8
https://pure-springs-67256.herokuapp.com/https://p24-calendars.icloud.com/published/2/MzgzNTAzMjUzODM1MDMyNdli1zQfYa9Vr5bBlos4nm7rdug6v6QPcHIeNJnOlfB3ZAX9EEwNZq5xVhQcI3PYMCp6o6qlj5Nq_O2LYzoimIQ
https://pure-springs-67256.herokuapp.com/https://p24-calendars.icloud.com/published/2/MzgzNTAzMjUzODM1MDMyNdli1zQfYa9Vr5bBlos4nm5YWavDSFe_Lr5AnoZbu8B7SjhuCjQmuvF087sroPCYG6qjLN4gP_FlBzz_UMCO2PI
https://pure-springs-67256.herokuapp.com/https://p24-calendars.icloud.com/published/2/MzgzNTAzMjUzODM1MDMyNdli1zQfYa9Vr5bBlos4nm6f8k8GND7B-EjmT3HumoSesNlayW7XEMxPO0udZx-NpCmh-mM0cwRy1v9L0DjOuTI
https://pure-springs-67256.herokuapp.com/https://p24-calendars.icloud.com/published/2/MzgzNTAzMjUzODM1MDMyNdli1zQfYa9Vr5bBlos4nm6ciqYtMYoa6vZZbYBYH0VCukbQM3nnxHWGeSGleTjtBzWShxsKt2tsKZh0wu3RmO8
Exactly that’s the problem. To avoid CORS issues on the stack user’s side, the developer used a forwarder ( aka Middleware, see below)
And the forwarder ist not available, perhaps Heroku shut down the app or the forwarder ran out of ressources (e.g. free accounts can run only about 500 hours a month across all apps in this account).
I doubt that. But that doesn’t matter. Even what you suggested, which would be the solution in a long term, by setting up the server to allow cross origin requests, doesn’t matter; the stack developer and the requesting API has to support this.
Further reads:
I don’t! Most RW sites run on Apache (htaccess), that’s why RealMac added the htaccess editor in RW8. RW doesn’t do well on IIS and I doubt many RW sites have the traffic requirements that would merit using NGINX as it doesn’t do shared hosting well.
What Web server do you think most RW users are using?
The setting up access-control-allow-origin is a single line in htaccess for each domain. The API for the actual calendar (iCloud, Google, etc) already support this otherwise the middleware wouldn’t work. Yes, the stack developer @weavium would need to make modifications.
The web-server https://pure-springs-67256.herokuapp.com/ itself is responding with a 200 status.
I don’t own Kalendar so I know little about it. Looking at the documentation it doesn’t show the user setting up their own Heroku account, so am I to assume that all Kalendar users share the “forwarding” account? If so, and the “free” account has run out why are other users not experiencing problems?
Many hosting providers are not allowing all possible settings (or even give access) to the .htaccess file. RW editor for this file has nothing to do with it.
Especially on simple / cheaper hosting plans, to avoid problems with customers randomly setting parameters and configuring their hosting unusable, if this makes sense (Think of reconfiguring the memory settings for PHP, setting up redirects as loop holes, and so forth… I found a thousand ways of killing a Apache by accident 
)
NO!
If you would have read and understood the the linked article, especially the second part, you wouldn’t have said this.
The middleware is NOT WORKING AS A BROWSER (google “curl”) and thus it’s not affected by CORS. THATS WHY THE MIDDLEWARE IS IN PLACE.
Yes, the dyno (the “virtual server”) is responding. But if you want to address the app (e.g. by calling the correct route, in this case with the appended URL), it responds 503, but not everytime. If you you’re new to web app development, backend / server development and Heroku, I am happy to give some insigts.
Yes.
And yes, I believe so.
And some other stacks here around as-well.
And many more apps, who use this server application.
In detail:
This is a node.js application written some years ago by Rob Wu from the netherlands (seven years, according to his Git) to avoid this issues and then others started to use it.
The official demo was available here: https://cors-anywhere.herokuapp.com/corsdemo, but it’s also shutdown because of “abuse”: PSA: Public demo server (cors-anywhere.herokuapp.com) will be very limited by January 2021, 31st · Issue #301 · Rob--W/cors-anywhere · GitHub
Years ago, someone used his code and deployed it to a free account to make it accessible, wich is also widely used.
Kalendar (and other stack developers) just adopted it and run into issues from to time. 
@willemn I would at least try do edit your .htaccess to see if it makes a change, but in the long term, the stack developer needs a reliable solution and is the only one who will be able to help.
Sorry for the big blurb here.
I personally believe that the proxy server / middleware / forwarder “Palm Springs” simply is no longer servicing properly. To be honest, a have some test projects running (mobile apps / node applications) who use palm springs and still work.
If you’re able to modify your .htaccess file (if you know what you’re doing, otherwise ask for some help from your hosting provider) as @teefers was mentioning. If it’s not working, only the stack developer can help by rethinking his stack development.
I’ve probably helped hundreds of people on almost as many hosting companies, almost all shared plans and most on the cheap side. I can’t tell you the last time I found anyone totally blocking htaccess files. It had to be nine or ten years ago. Yes, they might still block some directives, but it’s very difficult to kill the main Apache process with a local directives file (htaccess) that is overriding the default http header(mod_headers). You can mess up your the main Apache process with other httpd.conf but the htaccess file usually would only affect your spawned processes and not the main Apache process shared by others.
You wouldn’t be able to control Caching, authentication, compression, Access Control, redirects, Content Security Police and more without access to the http header. Ten years ago some of the cheaper hosting plans didn’t allow htaccess files, but with properly configured AllowOverride Directive there is really no risk to other users. If you’re on a plan that restricts access, it time to find another hosting company.
As for CORS Anywhere, what some people call middleware, others of us call a hack. It you think it’s good security to allow a 3rd party server to “override” your users browsers built-in security, then I guess use it. I can tell you that wouldn’t pass the most basic security audit and I’d never allow that on any website I was part of.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.