I am sending out an email with actionmailer through SparkPost. I have set the content-type the following ways:
in action model:
default content_type: 'text/html'
and in the model action:
headers['Content-Type'] = 'text/html'
I suspect that isn't the problem because when I send the email in development to mailcatcher it keeps the content-type and displays properly.
Even watching the production.log when it sends the email shows it sending it
Subject: Equipment Training for June
Mime-Version: 1.0
Content-Type: text/html;
charset=UTF-8
Content-Transfer-Encoding: quoted-printable
But when it arrives the message has been converted to:
Content-Type: text/plain;
I have tried receiving it with both gmail and office.com emails.
Almost forgot, for some reason it isn't happening on other mailers from the app which is why I initially thought it was a rails issue.
I figured it out, Sparkpost appears to convert html only emails to plain styling so that everyone will get it. I didn't have a .text.haml version of my mailer so it wasn't sending the email as a
Content-Type: multipart/alternative
Once I added that then Sparkpost would allow the multi-content to get through.
Related
For some strange reason, I cannot upload files or create folders in a drive using the MS Graph API. I can view/list and even delete without any issues. Same goes for personal OneDrive files...I can list and delete, but not upload or create folders. I can't even create an upload session. I have set up the API permissions correct as far as I can tell (due to the ability to list and delete), but something is amiss.
I'm using Ruby and its Net::HTTP class to make the HTTP requests, but I've tried with other languages as well, even the Github Javascript SDK (https://github.com/microsoftgraph/msgraph-sdk-javascript) and Java SDK (https://github.com/microsoftgraph/msgraph-sdk-java). Every attempt I make results in the same 400 (invalid request) error. My request looks like this:
PUT /v1.0/drives/b!0jlSfAMWs0mywYCiVQrxB8cBs6dbx0FDr8CYTNg4ITob3Q2lz0OER6Snzs1G_vHh/items/01L5VYWTF6Y2GOVW7725BZO354PWSELRRZ:/test.txt:/content HTTP/1.1
Accept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3
Accept: application/json
User-Agent: Ruby
Host: graph.microsoft.com
Authorization: Bearer <my auth code>
Content-Type: text/plain
Connection: close
Content-Length: 24
My test.txt file content
The error response back has no useful information for diagnosing my problem:
HTTP/1.1 400 Bad Request
Cache-Control: private
Content-Type: application/json
request-id: c42545c0-ee40-40f3-9c7d-19d0e69d8ac8
client-request-id: c42545c0-ee40-40f3-9c7d-19d0e69d8ac8
x-ms-ags-diagnostic: {"ServerInfo":{"DataCenter":"North Central US","Slice":"SliceC","Ring":"3","ScaleUnit":"003","RoleInstance":"AGSFE_IN_45"}}
Strict-Transport-Security: max-age=31536000
Date: Mon, 03 Aug 2020 16:23:47 GMT
Connection: close
Content-Length: 215
{
"error": {
"code": "invalidRequest",
"message": "Invalid request",
"innerError": {
"date": "2020-08-03T20:35:44",
"request-id": "c42545c0-ee40-40f3-9c7d-19d0e69d8ac8"
}
}
I've tried a few different paths for this PUT request to upload the file and get the same error in response:
sites/#{site_id}/drive/items/01L5VYWTF6Y2GOVW7725BZO354PWSELRRZ:/test.txt:/content
sites/#{site_id}/drive/root:/test.txt:/content
me/drive/items/01FF6DWVN6Y2GOVW7725BZO354PWSELRRZ:/test.txt:/content
me/drive/root:/test.txt:/content
My app registration has the following API permissions and I'm requesting each of these when making the OAuth access token request:
openid
email
profile
https://graph.microsoft.com/User.Read
https://graph.microsoft.com/Files.Read
https://graph.microsoft.com/Files.Read.All
https://graph.microsoft.com/Files.ReadWrite
https://graph.microsoft.com/Files.ReadWrite.All
https://graph.microsoft.com/Sites.Manage.All
https://graph.microsoft.com/Sites.Read.All
https://graph.microsoft.com/Sites.ReadWrite.All
Again - I get similar errors trying to create a folder in any drive or trying to create an upload session. These are both POST requests with a JSON body to a slightly different URL, but the end result is the exact same....a 400 error with absolutely no helpful information. Same thing happens at the 'beta' endpoint.
Microsoft won't help me unless I'm a "Unified Support or Premium customer". Every case I try to submit immediately is closed.
Anyone have any ideas?
Ok - an update to this. I ended up getting Microsoft O365 support involved and we did a Teams meeting where I screenshared and showed them the problem. They had me try a few things (including creating a brand new Sharepoint site) and the problem persisted. Needless to say, they were stumped themselves.
I then asked some colleagues to try to upload files to a Sharepoint site and it worked for them. Turns out, there was something strange wrong with my Azure app registration. I have no clue what it was because all its config was the exact same as my colleague's. So I ended up creating a brand new app registration and when I use that, everything started working.
Recently I come into a trouble with CORS(Cross Origin Resource Sharing) request on Safari, both OSX and iOS, while the same request works perfectly on Chrome and Firefox. I follow the documentation of W3C and handle preflight request on server side, my response is like:
HTTP/1.0 200 OK
Access-Control-Allow-Origin: http://192.168.1.96:4399
Access-Control-Allow-Methods: POST
Access-Control-Allow-Methods: GET
Access-Control-Allow-Methods: OPTIONS
Access-Control-Allow-Headers: Origin
Access-Control-Allow-Headers: Authorization
Access-Control-Allow-Headers: X-Requested-With
Access-Control-Allow-Headers: Accept
Access-Control-Allow-Headers: Access-Control-Request-Method
Access-Control-Allow-Headers: Access-Control-Request-Headers
Access-Control-Allow-Headers: DNT
Access-Control-Allow-Headers: X-CustomHeader
Access-Control-Allow-Headers: Content-Type
Access-Control-Max-Age: 0
Date: Fri, 25 Nov 2016 08:45:25 GMT
Origin: http://192.168.1.96:4399
Access-Control-Expose-Headers: Origin
Content-Encoding: gzip
Transfer-Encoding: chunked
Such response works fine on Chrome, Firefox, and Android Browser: a POST request is sent right after the preflight request. But on Safari, after server response the reflight request, I got such error message from console:
Failed to load resource: The network connection was lost.
I inspect the preflight response from server, but find it the same as above... After searching and trying so many times, I still can't make it work :-(
Is there anybody that come across the problem before? Could anyone figure out what mistake I've made?
Thanks very much in advance!
It's all about Safari add origin to OPTIONS request header Access-Control-Request-Headers.
So to fix it you should enable this header in Access-Control-Allow-Headers in response.
PS: see similar question CORS request not working in Safari
HTTP digest authentication no longer works in our app since iOS 10 due to wrong nonce-count in Authorization: Digest header generated by NSURLSession.
The same code works in iOS 9, but fail to auth in iOS 10
Create a POST request with NSURLRequest
Fire it with NSURLSession
Handle NSURLAuthenticationMethodHTTPDigest in urlSession(_:didReceive:completionHandler:) delegate
The server responds with a 401 and qop="auth" string as expected
The app requests again with the Authorization: Digest header set.
According to RFC2617:
nonce-count
This MUST be specified if a qop directive is sent (see above), and
MUST NOT be specified if the server did not send a qop directive in
the WWW-Authenticate header field. The nc-value is the hexadecimal
count of the number of requests (including the current request)
that the client has sent with the nonce value in this request. For
example, in the first request sent in response to a given nonce
value, the client sends "nc=00000001". The purpose of this
directive is to allow the server to detect request replays by
maintaining its own copy of this count - if the same nc-value is
seen twice, then the request is a replay. See the description
below of the construction of the request-digest value.
However, the nonce-count start at "nc=00000002" even for the first request in iOS 10, which cause the server to reject it.
Expect server response 200 OK
iOS 9 & Before:
POST /Tunnel/Message.aspx HTTP/1.1
Host: 172.18.70.12:3454
Accept: */*
Content-Type: application/xml
User-Agent: iViewer/1 CFNetwork/758.5.3 Darwin/15.6.0
Connection: keep-alive
Cookie:
AuthType: digest
Accept-Language: zh-tw
Content-Length: 69
Accept-Encoding: gzip, deflate
Authorization: Digest username="admin", realm="ND8422P",
nonce="cc17a78cdd96d54e012eadefe7d13d82", uri="/Tunnel/Message.aspx",
response="51587db4bcf6eeece68c4ec21108f170",
cnonce="47b8df8a980f280038834b7817250e90", nc=00000001, qop="auth"
<?xml version="1.0" encoding="UTF-8"?><GetServerInfo></GetServerInfo>
HTTP/1.0 200 OK
Cache-Control: no-store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache
Content-Type: text/xml
Content-Length: 1127
iOS 10:
POST /Tunnel/Message.aspx HTTP/1.1
Host: 172.18.70.12:3454
Accept: */*
Content-Type: application/xml
User-Agent: iViewer/1 CFNetwork/808.0.2 Darwin/16.0.0
Connection: keep-alive
Cookie:
AuthType: digest
Accept-Language: en-us
Content-Length: 69
Accept-Encoding: gzip, deflate
Authorization: Digest username="admin", realm="ND8422P",
nonce="4b8bf8549da0c3010f031472e95f387d", uri="/Tunnel/Message.aspx",
response="91cf44bc0aadf2f743164d03b5c708c7",
cnonce="b5f9e6c69e19c1b396298d68f2aefe7e", nc=00000002, qop="auth"
<?xml version="1.0" encoding="UTF-8"?><GetServerInfo></GetServerInfo>
HTTP/1.0 401 Unauthorized
WWW-Authenticate: Digest qop="auth", realm="ND8422P", nonce="8e8b0538bb08876ac4d8203f1d14e9ac"
CSeq: 0
Is anyone facing the same issue?
The only related post I could find is:
Apple Developer Forums : Problem of the digest authentication, but no further information.
How do you fix it or get workaround on client app side without asking server side to ignore the wrong nonce-count?
Thanks.
Apple Developer Technical Support confirm that is a bug of iOS 10.
Hope it will be fixed soon.
Thank you for contacting Apple Developer Technical Support (DTS).
We believe this issue is a bug. Please file a bug report using the Bug Reporter tool https://developer.apple.com/bug-reporting/.
Update:
Apple fixed this issue in iOS 10.2 Beta 3
Chances are, the OS is sending a HEAD request first, and your server-side code isn't getting it. I would try running Charles Proxy to verify that this is what's happening.
That said, skipping a nonce count is not inherently an indication of any sort of attack. It could occur even in iOS 9 if a request got lost somehow (e.g. a network error). What's important is to ensure that the count doesn't go backwards. So I would argue that your server code is buggy and should not be rejecting that to begin with.
We have the same problem in our company as described here:
Cordova app can't connect with Dynamics NAV Web-Service (ODATA) after update to iOS 10
We can reproduce the issue both in our App and the Safari Browser with iOS 10 devices. There does not seem to be a simple client side workaround. We opened a Bug Report with Apple.
In our case the problem was solved with the 10.2 Beta release.
I'm sending mail via mandrill smtp server.
The embedded images shows up as attachments.
When using another smtp host they are displayed inline as expected.
This is how the raw email sent via mandrill looks like,
--_av-wPsilWaNBD9LTkJ6pVYNCQ
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="header.jpg"
And that same email sent via my other smtp server,
------=_Part_2_149158871.1452888744955
Content-Type: application/octet-stream; name=header.jpg
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename=header.jpg
Content-ID: <1.1452888744955#10.0.1.2>
Any ideas what I'm doing wrong? Or is this not possible with mandrill?
Mails are sent from a java application using javax.
I try the guide here: Path Developers Docs
I can get access token from Path API.
But I can not send post photo request "POST /1/moment/photo".
Does anyone can do it?
I used gtw-oauth2 to get access token from Path API.
If you see the request format
POST /oauth2/access_token HTTP/1.1
Host: partner.path.com
Content-Type: application/x-www-form-urlencoded
Content-Length: <LENGTH>
grant_type=authorization_code&client_id=CLIENT&client_secret=SECRET&code=CODE
Content-Length line is not required, in getting permanent access token
code=CODE - was very confusing, and i see you can get temporary access token, but can't get permanent access token, in this line, capital CODE MUST BE REPLACED WITH TEMPORARY ACCESS TOKEN
don't change grant_type=authorization_code only
I think this will help you a lot
POST /oauth2/access_token HTTP/1.1
Host: partner.path.com
Content-Type: application/x-www-form-urlencoded
Content-Length:
grant_type=authorization_code&client_id=CLIENT&client_secret=SECRET&code=CODE