I have implemented caldav api's to manage icloud calendar and everything working as expected.
But now I am trying sent event with description includes html content instead of plain text. I had done my research and couldn't be success.
Below is sample API and screenshot of event in icloud calendar.
PUT /home/meeting.ics HTTP/1.1
Host: ...
Content-Length: ...
Content-Type: text/calendar; charset=utf-8
BEGIN:VCALENDAR
BEGIN:VEVENT
UID:test123
SUMMARY:Test Event
DESCRIPTION:Hi User <br/><br/> Text...<br/>Note : </br><br/>Thank you
DTSTART:20180920T080000Z
DTEND:20180920T170000Z
END:VEVENT
END:VCALENDAR
In the above screenshot, we can see in notes section html tags are displayed. I think it's because icloud calendar considering entire message as text. Here I am looking for a solution to make text align with html.
Any help would be appreciated. Thanks in advance.
The ics spec RFC5545 doesn't specifically allow html in the event description. It suggests that ALTREP may point to an alternate HTML representation https://www.rfc-editor.org/rfc/rfc5545#section-3.2.1
More importantly calendar applications may not support it and deal with any html in different ways: strip it or show raw html.
See also Does icalendar support HTML and CSS? and https://icalevents.com/4019-ics-feed-generation-with-html/
(comment reposted as answer as suggested by hnh)
Related
I am currently trying to implement this solution here. The solution seems pretty simple and possible since I am the owner of both of the hosts. On mysite1.com I have added the following img tag.
<img src="//mysite1.com.com/cookie_set/" style="display:none;">
On my site2.com (django), I have a view like so:
def cookie_set(request):
response = HttpResponse()
response.set_cookie('my_cookie', value='awesome')
return response
When I release this code live. I get the following error:
Cross-Origin Read Blocking (CORB) blocked cross-origin response https://www.mysite2.com/cookie_set/ with MIME type text/html. See https://www.chromestatus.com/feature/121212121221 for more details.
I thought that maybe if I just added "Access-Control-Allow-Origin" in my view this might fix things, but according the docs here: https://www.chromium.org/Home/chromium-security/corb-for-developers, there's one more consideration:
For example, it will block a cross-origin text/html response requested from a or tag, replacing it with an empty response instead.
Are my assumptions correct? After adding the correct headers should I just change the content-type to something other than text/html?
Ultimately, my final goal is I would like to set a cookie for a different domain that I have control of (ideally without a redirect).
Best solution: use a different tag for this. (i.e. iframe).
The point behind CORB is to prevent certain tags from being used for XSSI data injection So img tags requests should not return text/html, application/json, or xml content types.
So unless the call to img tag really is for capturing the request itself (for referrer tracking, for example), then you get much more versatility by executing in an iframe anyway (like for SSO-redirection workflows).
See also: Setting third party cookie by using 1x1 <img> tag - Javascript doesn't drop cookie
I fixed this for image files by updating the Content-Type metadata under Properties in S3 - image/jpeg for JPEG files and image/png for PNG files.
My application uploads image files via multer-s3 and it seems it applies Content-Type: 'application/x-www-form-urlencoded'. It has a contentType option with content-type auto-detect feature - this should prevent improper headers and fix the CORB issue.
It seems the latest Chrome 76 version update includes listening to remote file URL headers, specifically Content-Type. CORB was not an issue for other browsers such as Firefox, Safari, and in-app browsers e.g. Instagram.
I have to debug a website that uses a swf to send amf posts to a flex2gateway.
In Firefox's "Firebug > Net" I see the POST url and when I click on it, the Post tab shows scrambled jiberish:
The response is also scrambled:
But the headers and cookies are not scrambled:
How can I unscramble the post so that I can create a curl with the proper post values. And how can I unscramble the response?
AMF is a binary format. As such Firebug and Chrome Dev Tools don't do a very good job of being able to read them. In the past, I have used a product called ServiceCapture to 'read' AMF messages. Charles is another product that can do this.
[SOLVED] Please see my answer.
Any POST request sent with the
Content-Type: multipart/form-data; boundary=xYzZY results in the request.POST QueryDict{} to be empty. Changing the Content-Type to multipart/form-data also results in the same error.
Removing the Content-Type altogether results in the values getting passed correctly, and I can access them in request.POST.
I have tried disabling the Csrf middleware, using #csrf_exempt, and also tried the same on multiple servers. Didn't change the empty POST condition.
While reading up on Django framework and POST content-type, I read that it (no longer) assumes a default content-type and therefore must be supplied with the correct one (I do not have a link to the article in question.) I think something similar is happening here, with django not being able to parse the parameters with the given content-type (but leaving it blank lets the parser interpret it with the default value).
What I am having trouble with is, that the Content-Type value supplied is perfectly valid (multipart/form-data with boundary). So why does django refuse to load it in the POST dictionary?
** I am not in control of the Content-Type sent in the POST data.
** UPDATE: reading from request.body shows that all the POST parameters are being received. They're just not present in request.POST
** UPDATE: I'm using Runscope to test POST requests.
As mentioned in the UPDATE, I was using Runscope to test the POST data. I realised that the error was with the way Runscope handled multipart/form-data. I raised the issue with support and got notified that Runscope does not support multipart as of now. I've copied the relevant information here:
We hope to support multipart form uploads capabilities for the future, but don't have a timeline on when this will be available. Some customers have made this work in their Radar tests (https://www.runscope.com/docs/radar) by pasting in the raw multipart-formatted body or unicode string input body into the request and making sure to include the applicable 'Content-type' header value with the correct boundaries. Some examples for building a multipart/form-data POST request can be found here: http://chxo.com/be2/20050724_93bf.html
For Runscope URLs, multipart data is passed through unmodified. However, the request editor and retries from the Traffic Inspector (https://www.runscope.com/docs/inspector) do not currently support multipart data which is why your request retry did not work. Additionally, request and response bodies larger than 1 MB are not saved for viewing after the request has been sent.
Using another service solved this for me.
You are (in a manner) in control of Content-Type. What you're looking for is enctype. You can use it as following:
<form method="POST" action="." enctype="multipart/form-data">
enctype is only required when you are uploading a file, otherwise, it's not.
I'm trying to publish a post on my facebook page using RestFB.
My code is as follows:
FacebookType publishResponse = facebookClient.publish(pageId + "/feed", FacebookType.class,
Parameter.with("message", message),
Parameter.with("picture", picture),
Parameter.with("link", link),
Parameter.with("description", description));
And my parameters have the following values:
message: Test+test+test
picture: https%3A%2F%2Fcom-smallteaser-local-photo.s3.amazonaws.com%2Fskydivemag%25232fdefcfa-c7b2-4c0d-8504-9942ccd9a4b0%2523648%25230%25232592%25232592%2523292%2523292
link: http%3A%2F%2Flocalhost%3A9000%2Farticle%2F20130503-test-test-test
description: This+is+just+a+test
I am getting the exception:
FacebookOAuthException: Received Facebook error response of type OAuthException: (#100) picture URL is not properly formatted]
I read here that i can add a picture with just providing an URL and it specifically says that it is meant for 'App developers who host their images on Amazon S3 or a similar service'.
Any idea what i'm doing wrong?
I think it’s not actually the “formatting” of the picture URL, but the content it returns:
https://com-smallteaser-local-photo.s3.amazonaws.com/skydivemag%232fdefcfa-c7b2-4c0d-8504-9942ccd9a4b0%23648%230%232592%232592%23292%23292
is delivered with a Content-Type: application/octet-stream response header (as you can see here) – and that might make Facebooks scraper think that this is not really an image resource.
So you will have to figure out how configure your hosting space to deliver these images with a correct Content-Type, for example img/jpeg or img/png.
I got this problem, but only on older Android devices, not on a desktop. I could see in the server logs that there was a difference:
When accessing the URL on a desktop, Facebook does request the picture URL.
When accessing the URL on an older Android device, Facebook does not request the picture URL.
It turned out that I was using window.location.origin in constructing the absolute URL, which according to http://www.hyperink.com/blog/?p=18 only works on Webkit. It was solved by replacing, as the post suggests,
window.location.origin
by
window.location.protocol + “//” + window.location.hostname
I have a Django admin action called "Email selected members". Check some members and click the Go button and the user's mail program is opened. The emails of the selected members have been pre-entered.
This works by a Django HttpResponseRedirect(uri) with the uri being "mailto:email1,email2..
where the addresses email1, email2 ... were looked up on the server.
The only problem is that that the browser re-directs to a blank page as well a opening the client mail program.
Is there any way to avoid this?
-- Peter
This question is a little old, but I just went through this and I think I can help anyone looking for an answer in the future.
I ran into this problem because the website I was building had a built-in tracking system that tracked the URLs of outbound links for self-hosted ads. If I don't redirect, there is no way (without changing the way it was implemented) to track the click, since I'm not using an API or anything.
The easy fix was to do what you did, sending back an HttpResponse() whose content is the meta tag
<meta http-equiv="refresh" content="0;url=mailto:youremail#test.com" />
This causes the page to refresh on load, which triggers the mailto: action.
Now we're left with an open window, but we can't close the window using Javascript's window.close() method. I do believe that this solution should work, however. Call that Javascript function after the refresh has been successful.
Unfortunately, I haven't tested this, but these two methods should accomplish a mailto: redirect that does not leave a blank window/tab behind.
Hope this helps!
Don't use HttpResponseRedirect. Just make the mailto: line a link. Email selected members
I don't think it is possible. RFC 2616 says re 302 redirect:
The temporary URI SHOULD be given by
the Location field in the response.
Unless the request method was HEAD,
the entity of the response SHOULD
contain a short hypertext note with a
hyperlink to the new URI(s)
So the blank page that I see is the (very) short hypertext note. The browser gets the redirect instruction, pops up a temporary page with the redirect message, then retrieves the redirected URL. But with a mailto: URL the temporary page obviously remains.