I'm new to web programming, as you are about to see.
I'm trying to periodically retrieve files from Unfuddle using their API. I tried their first code example and it seems to return valid information from my HTTP GET call, but I don't know how to use this information to get specific files onto my hard drive. How is this done?
Here is my exact HTTP GET call and response (except for the password being replaced):
bmihura#bmihura-PC ~
$ curl -i -u bmihra:password -X GET \
> -H 'Accept: application/xml' \
> 'http://spowertech.unfuddle.com/api/v1/projects/projects.xml'
HTTP/1.1 302 Found
Server: nginx/1.0.5
Date: Fri, 17 Aug 2012 11:53:23 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 3.0.8
Vary: Accept-Encoding
Cache-Control: no-cache
Set-Cookie: authenticated=; domain=.unfuddle.com; path=/; expires=Thu, 01-Jan-19 70 00:00:00 GMT
Set-Cookie: authenticated=false; path=/; expires=Fri, 17-Aug-2012 13:51:24 GMT
Set-Cookie: unfuddle_secure=; domain=.unfuddle.com; path=/; expires=Thu, 01-Jan- 1970 00:00:00 GMT
Set-Cookie: _unfuddle_session=; domain=.unfuddle.com; path=/; expires=Thu, 01-Ja n-1970 00:00:00 GMT
Set-Cookie: _unfuddle_session=BAh7BjoPc2Vzc2lvbl9pZCIlZGIzOTlmMTcxZGIwZjE4MDRhZW RkZGVmOGI4YjIxNzM%3D--0833ed386e5cd62894bb8dd787d856545897df35; path=/; expires= Fri, 17-Aug-2012 13:53:24 GMT; HttpOnly
Location: https://spowertech.unfuddle.com/projects/projects
Content-Length: 115
Status: 302
<html><body>You are being redirected.</body></html>
You need to use https instead of http in the url at the bottom - i.e.
curl -i -u bmihra:password -X GET \
-H 'Accept: application/xml' \
'https://spowertech.unfuddle.com/api/v1/projects/projects.xml'
In addition, to get it to work via my windows machine I had to replace the ' with " in the -H and remove the ' around the url. So I ended up using
curl -i -u bmihra:password -X GET \
-H "Accept: application/xml" \
https://spowertech.unfuddle.com/api/v1/projects/projects.xml
Hope that helps!
Related
When using this command to stream upload to a Apache/PHP server
curl -X POST \
-i --data-binary #customfile.app \
-H "Transfer-Encoding: chunked" \
-H "Content-Type: application/app" \
-H "X-CustomHeader1: customvalue1" \
-H "X-CustomHeader2: customvalue2" \
-H "X-CustomHeader3: customvalue3" \
-H "X-CustomHeader4: customvalue4" \
-H "X-CustomHeader5: customvalue5" \
-H "X-CustomHeader6: customvalue6" \
--ignore-content-length \
--progress-bar -vvv \
http://[DOMAIN]/upload.php
The command hangs as follows:
* Hostname was NOT found in DNS cache
* Trying [IP_ADDRESS]...
* Connected to [DOMAIN] ([IP_ADDRESS]) port 80 (#0)
> POST /upload.php HTTP/1.1
> User-Agent: curl/7.37.1
> Host: [DOMAIN]
> Accept: */*
> Transfer-Encoding: chunked
> Content-Type: application/app
> X-CustomHeader1: customvalue1
> X-CustomHeader2: customvalue2
> X-CustomHeader3: customvalue3
> X-CustomHeader4: customvalue4
> X-CustomHeader5: customvalue5
> X-CustomHeader6: customvalue6
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
HTTP/1.1 100 Continue
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Content-Type: text/html; charset=UTF-8
Content-Type: text/html; charset=UTF-8
< Date: Thu, 12 Feb 2015 11:10:17 GMT
Date: Thu, 12 Feb 2015 11:10:17 GMT
* Server Apache is not blacklisted
< Server: Apache
Server: Apache
< Vary: Content-Type
Vary: Content-Type
< Content-Length: 0
Content-Length: 0
< Connection: keep-alive
Connection: keep-alive
* no chunk, no close, no size. Assume close to signal end
<
Now, when the no chunk, no close, no size. Assume close to signal end message appears I do a checksum on both the local and server file to prove they are both the same, which they are. Meaning that the file successfully uploads, but for some reason the connection is not closed.
Why is that and how do I resolve it? Can I tell cURL to close the connection when the whole file has been uploaded? Thanks
You specifically tell curl to ignore the content-length set by the server. Because of this the end of the response will be assumed to be connection close. But the server does not close because it waits for more requests.
Apart from that: I don't think you can just add "Transfer-Encoding: chunked" as a custom header. It is not enough to tell the server that the content will be sent in chunks but curl actually has to use chunked encoding which it probably does not.
I had a funny case when this happened with a JSP page.
Flushing a newline helped:
<%
out.println("");
out.flush();
%>
i'm trying now to upload zip attachment through REST API but no success. It works, when I'm trying to attach picture, but when I use the same command for zip
curl -D- -u Bogdan:Password -X POST -H "X-Atlassian-Token: nocheck"
-F "file=#xla-snapshot.zip" http://localhost:5555/rest/api/2/issue/XA-1/attachments
I have such response:
HTTP/1.1 100 Continue HTTP/1.1 404 Not Found Server: Apache-Coyote/1.1
X-AREQUESTID: 1352x1015x1 X-ASEN: SEN-2117746 Set-Cookie:
JSESSIONID=97A763E5E09F7F8476CEDF07A2ACD7C6; Path=/; HttpOnly
X-Seraph-LoginReason: OK Set-Cookie:
atlassian.xsrf.token=B7X0-QLNV-RIK8-C6T9|aca131a97f4fdb61cebd0bfb6681c66824d62464|lin;
Path=/ X-ASESSIONID: nzll4r X-AUSERNAME: Bogdan Cache-Control:
no-cache, no-store, no-transform X-Content-Type-Options: nosniff
Content-Type: application/json;charset=UTF-8 Transfer-Encoding:
chunked Date: Thu, 20 Nov 2014 21:32:11 GMT
When I modified and explicitly said content type that it is zip
url -D- -u Bogdan:Password -X POST -H "Content-Type:
application/zip" -H "X-Atlassian-Token: nocheck" -F
"file=#xla-snapshot.zip"
http://localhost:5555/rest/api/2/issue/XA-1/attachments
I got an "Unsupported Media Type" response:
HTTP/1.1 100 Continue HTTP/1.1 415 Unsupported Media Type Server:
Apache-Coyote/1.1 X-AREQUESTID: 1353x1016x1 X-ASEN: SEN-2117746
Set-Cookie: JSESSIONID=6225FF25F6D71BADB6890C9F448608B6; Path=/;
HttpOnly X-Seraph-LoginReason: OK Set-Cookie:
atlassian.xsrf.token=B7X0-QLNV-RIK8-C6T9|e2c7fc222c74c37f5080150df1cd865eaa8daf7e|lin;
Path=/ X-ASESSIONID: 1lbjx70 X-AUSERNAME: Bogdan
X-Content-Type-Options: nosniff Content-Type: text/html;charset=utf-8
Content-Language: en Content-Length: 1092 Date: Thu, 20 Nov 2014
21:33:07 GMT
Is it possible actually to upload archives via REST Api?
Actually the problem was that the file was too big for download, the limit is 10 Mb, and I was trying to upload more than it.
Quite sad that looking at this documentation https://docs.atlassian.com/jira/REST/latest/#d2e4527 there is no information about 404, when it can happen. And no information how you can guess the real cause
I'm planning on using CouchDB's built-in cookie authentication for my app (note that this isn't a CouchApp, I'm using a web server between my client and db).
So when a user first logs in with their credentials:
Credentials are sent to CouchDB from web client via web server
CouchDB authenticates credentials and returns a Set-Cookie header
This header is sent to the web client and means that all subsequent requests for database operations just pass on the Cookie header to CouchDB via the web server.
Whilst I've been able to ascertain that:
You can keep using [the cookie] token for 10 minutes by default. After 10 minutes you need to authenticate your user again. The token lifetime can be configured with the timeout (in seconds) setting in the couch_httpd_auth configuration section.
It isn't clear to me if this 10 minute period is (or can be set to be) a sliding window.
By this I mean; if the user continues to use the application for the whole 10 minutes (sending the cookie along on each request), will the cookie automatically be re-set (in a similar way to FormsAuthentication cookies in .NET) until a period of in-activity for 10 minutes?
References used
http://guide.couchdb.org/draft/security.html#cookies
http://wiki.apache.org/couchdb/Security_Features_Overview
For a browser, the (configurable) 10-minute period is a sliding window. Every time CouchDB responds to a request, it will update the cookie to a new value, effectively refreshing the login.
For a client, you must remember to reset the cookie value when you see a Set-Cookie header (or pass it through to your own client in your case).
For example, I have a short timeout (30 seconds):
$ curl http://admin:admin#localhost:5984/_config/couch_httpd_auth/timeout
"30"
Next I will:
Log in
Wait a little while
Check my session with the cookie, before the timeout
Wait for the timeout
Check my session with the cookie again, after the timeout
(Quickly) check my session with the new cookie CouchDB set in step 3
Notice that the first confirmation has {"name":"me"} (I am logged in); the second has {"name":null} (I am logged out); but the third has {"name":"me"} again (I am still logged in due to using the updated cookie).
$ curl -X POST -i localhost:5984/_session -d name=me -d password=secret
HTTP/1.1 200 OK
Set-Cookie: AuthSession=bWU6NEY5QjQ3QTA6Ao6zetUZUxkno37ULd2qdRRjmsc; Version=1; Path=/; HttpOnly
Server: CouchDB/1.2.0 (Erlang OTP/R15B)
Date: Sat, 28 Apr 2012 01:28:00 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 35
Cache-Control: must-revalidate
{"ok":true,"name":"me","roles":[]}
$ sleep 20
$ curl -i localhost:5984/_session -H Cookie:AuthSession=bWU6NEY5QjQ3QTA6Ao6zetUZUxkno37ULd2qdRRjmsc
HTTP/1.1 200 OK
Set-Cookie: AuthSession=bWU6NEY5QjQ3QkM6WonDdsAdO8p7QUlLWCZQXVAfcvU; Version=1; Path=/; HttpOnly
Server: CouchDB/1.2.0 (Erlang OTP/R15B)
Date: Sat, 28 Apr 2012 01:28:28 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 165
Cache-Control: must-revalidate
{"ok":true,"userCtx":{"name":"me","roles":[]},"info":{"authentication_db":"_users","authentication_handlers":["oauth","cookie","default"],"authenticated":"cookie"}}
$ sleep 10
$ curl -i localhost:5984/_session -H Cookie:AuthSession=bWU6NEY5QjQ3QTA6Ao6zetUZUxkno37ULd2qdRRjmsc
HTTP/1.1 200 OK
Server: CouchDB/1.2.0 (Erlang OTP/R15B)
Date: Sat, 28 Apr 2012 01:28:43 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 140
Cache-Control: must-revalidate
{"ok":true,"userCtx":{"name":null,"roles":[]},"info":{"authentication_db":"_users","authentication_handlers":["oauth","cookie","default"]}}
$ curl -i localhost:5984/_session -H Cookie:AuthSession=bWU6NEY5QjQ3QkM6WonDdsAdO8p7QUlLWCZQXVAfcvU
HTTP/1.1 200 OK
Set-Cookie: AuthSession=bWU6NEY5QjQ3RDA69pqrNVd-ClZ7_v4SkcghdZRRhCs; Version=1; Path=/; HttpOnly
Server: CouchDB/1.2.0 (Erlang OTP/R15B)
Date: Sat, 28 Apr 2012 01:28:48 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 165
Cache-Control: must-revalidate
{"ok":true,"userCtx":{"name":"me","roles":[]},"info":{"authentication_db":"_users","authentication_handlers":["oauth","cookie","default"],"authenticated":"cookie"}}
In CouchDB 1.2.0 and later, you can set _config/couch_httpd_auth/allow_persistent_cookies to "true" and it makes things easier to see. The cookie will have an obvious "Expires" flag which you can see is always set to the current time plus your timeout value.
I am a bit stuck in authenticating my app and get an access token, when following this instructions: http://developers.flattr.net/v2/
Step 1, Authenticate works fine. I get back the code, and my app is listed in my Settings/Applications with the correct scope.
Then I try to get the access token via the following curl command:
curl -v --user MY_KEY:MY_SECRET -H "Content-Type: application/json"\
-X POST -d '{"grant_type": "authorization_code",\
"redirect_uri": "http://localhost/", "code": "MY_CODE"}'\
https://flattr.com/oauth/token
Unfortunately I always get "invalid_request"
< HTTP/1.1 400 Bad Request
< Strict-Transport-Security: max-age=500
< Set-Cookie: PHPSESSID=d9972s9r5a7t4p0ch4chc4dqh2; path=/; domain=.flattr.com; HttpOnly
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store
< Pragma: no-cache
< Content-Type: application/json; charset=utf-8
< Content-Length: 291
< Connection: close
< Date: Wed, 16 Nov 2011 22:38:30 GMT
< Server: lighttpd
<
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
{"error":"invalid_request","error_description":"The request is missing a required parameter, includes an unsupported parameter or parameter value, repeats a parameter, includes multiple credentials, utilizes more than one mechanism for authenticating the client, or is otherwise malformed."}
Thanks!
I found a bug in the process and it is now smashed. Should be working smooth if you try the request again!
I'm building a JSON API on top of devise in order to be able to communicate from mobile devices.
So far so good, I am able to create a user account, to get an auth_token. But when I am trying to perform a PUT request, I get some problems , for example the update action for the user. The behavior is really stange, and I can't figure out what is wrong.
curl -i -H "Accept: application/json" 'http://localhost:3000/users' -X PUT -d 'auth_token=A830ALUv7ztTdSfl3qxFgi13BJpEf6VzNYe4yk8rEhVxbYYlOc0YMtTGMxkz&user[name]=plop'
Returns
HTTP/1.1 401 Unauthorized
Connection: close
Date: Wed, 02 Mar 2011 06:41:29 GMT
Content-Type: application/json; charset=utf-8
Cache-Control: no-cache
X-UA-Compatible: IE=Edge
X-Runtime: 0.157513
Transfer-Encoding: chunked
{"error":"You need to sign in or sign up before continuing."}
On the logs on the server i get this .... Really strange.
Started PUT "/users" for 127.0.0.1 at 2011-03-01 22:41:29 -0800
Processing by Users::RegistrationsController#update as JSON
Parameters: {"auth_token"=>"A830ALUv7ztTdSfl3qxFgi13BJpEf6VzNYe4yk8rEhVxbYYlOc0YMtTGMxkz", "user"=>{"name"=>"plop"}}
Completed in 1ms
Whereas if I modify just the name of the post value from user to users form example, the request works
HTTP/1.1 200 OK
Connection: close
Date: Wed, 02 Mar 2011 06:43:30 GMT
Content-Type: application/json; charset=utf-8
ETag: "5e1311709931861e469ce2c8a3b2d0e6"
Cache-Control: max-age=0, private, must-revalidate
X-UA-Compatible: IE=Edge
Set-Cookie: _u_session=BAh7CEkiGXdhcmRlbi51c2VyLnVzZXIua2V5BjoGRVRbCEkiCVVzZXIGOwBGWwZvOhNCU09OOjpPYmplY3RJZAY6CkBkYXRhWxFpUGGaQG%2FaX1pAfhpAaRpAexpAGkAaQ1JIiIkMmEkMTAkMDVBeDczV29UdVFEZHQxZ1JjN0NXdQY7AFRJjW9uRGlzcGF0Y2g6OkZsYXNoOjpGbGFzaEhhc2h7BjoLbm90aWNlSSIrWW91IHVwZGF0ZWQgeW91ciBhY2NvdW50IHN1Y2Nlc3NmdWxseS4GOwBUBjoKQHVzZWRvOghTZXQGOgpAaGFzaHsASSIPc2Vzc2lvbl9pZAY7AEYiJTcyNmIyZjJiODZhOTBiNjUwZDlhZmIwMzA5MTRkMTlm--0e15953fd7edecb0e08255349c4e55f1eddc8d81; path=/; HttpOnly
X-Runtime: 0.162436
Transfer-Encoding: chunked
{"redirect":"/","status":"ok"}
I precise that, even without my code(For the API) I can't perform this request !!!!
Thanks for your help !
I don't believe that Devise handles JSON calls, there is an open issue on github that is scheduled for the 1.3 release to address this problem.