When trying to POST data to my tastypie api, I always get error code 401, even when using the Django admin account for authentication and authorization. My Django server is running as development server through "python manage.py runserver IP"
I'm using the latest master-branch of tastypie and Django 1.4.3
here are parts of my api.py
class QueueResource(ModelResource):
class Meta:
queryset = Queue.objects.all()
resource_name = 'queue'
]
my curl command:
curl --dump-header -H "Content-Type: application/json" -X POST --data '{"qid": "4", "msg": "An error occured!"}' http://IP/api/fail/
the corresponding error message:
HTTP/1.0 401 UNAUTHORIZED
Date: Wed, 13 Feb 2013 19:16:00 GMT
Server: WSGIServer/0.1 Python/2.7.3
X-Frame-Options: SAMEORIGIN
Content-Type: text/html; charset=utf-8
Does anyone of you has an idea why I'm getting this error code?
You should define authorization that you will use in the meta class of the resource.
Default one is ReadOnlyAuthorization.
More info you can find Here
Like what UnLiMiTeD said, you need to define Authorization.
from tastypie.authorization import Authorization
class QueueResource(ModelResource):
class Meta:
authorization = Authorization()
queryset = Queue.objects.all()
resource_name = 'queue'
This will make the QueueResource have no authorization restrictions. You can post to it without verifying any credentials.
The default authorization method is a ReadOnlyAuthorization.
Related
This question has been asked before but none of the solutions has worked for me.
I've created a bash script to register a new user on my key cloak server. The bashscript is shown below:
#!/bin/sh
RESULT=$(curl -s --location --request POST 'http://localhost:8180/auth/realms/master/protocol/openid-connect/token' --header 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'grant_type=client_credentials' --data-urlencode 'client_id=admin-cli' --data-urlencode 'client_secret=12345678-12a3-1234-bc12-d12345678910');
TOKEN=$(echo $(echo "$RESULT" | jq .access_token))
TOKEN=$(echo "${TOKEN//\"}")
echo "$TOKEN\n\n"
USER=$(curl --location -v --request POST 'http://localhost:8180/auth/admin/realms/MyMarketplace/users' --header 'Content-Type: application/json' --header "Authorization: Bearer $TOKEN" --data-raw '{"enabled":"true", "username":"app-user"}');
echo $USER;
When I run this script, I keep getting the following output:
HTTP/1.1 403 Forbidden
< Connection: keep-alive
< X-XSS-Protection: 1; mode=block
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< Content-Type: application/json
< Content-Length: 25
< Date: Fri, 17 Jul 2020 20:11:40 GMT
<
{ [25 bytes data]
100 66 100 25 100 41 974 1597 --:--:-- --:--:-- --:--:-- 1640
* Connection #0 to host localhost left intact
{"error":"unknown_error"}
I'm not sure why. Here's what I've tried:
I've made sure that the URL that I'm sending the request to is correct.
I've made sure that the username is unique and that I've provided all mandatory fields.
In the MyMarketplace realm, I added a realm role 'admin' with a client role 'manage-users' from client 'realm-management' and I assigned this realm role to my client's scope (as per the steps given in this answer)
In the Master realm, I assigned the manage-users role to the client admin-cli's scope.
None of these has yielded any results so I've run out of options.
I would greatly appreciate it if someone could help me understand what I'm missing.
use http://localhost:8180/auth/realms/MyMarketplace/protocol/openid-connect/token to obtain access_token and give admin-cli client manage-users role from realm-management client in Service Account Roles and then call http://localhost:8180/auth/admin/realms/MyMarketplace/users with access token in header and "enabled": true, "username": "user" body.
make sure your enabled boolean look like this one and dont use "" I think keycloak reads your request as String.
I think it will fix your problem.
Use and configure admin-cli client as you did, but in MyMarketplace realm. Don't use the master realm.
I'm trying to use App ID to do user authentication/authorization against a service running in Kubernetes from a CLI tool.
I've provisioned App ID and configured SAML identity provider. I added an application and got the tenant id, client id, and client secret. I also added the appid-auth annotation to the Kubernetes ingress definition.
According to the documentation here https://cloud.ibm.com/docs/services/appid?topic=appid-obtain-tokens, it should be pretty strait forward via curl, but I'm getting Error - cloud directory is OFF.
Here's an example with the credentials X'd out.
$ curl -iX POST \
> https://us-south.appid.cloud.ibm.com/oauth/v4/XXXX/token \
> -H 'Authorization: Basic XXXXXXXXX' \
> -H 'Content-Type: application/json' \
> -H 'Accept: application/json' \
> -d '{"grant_type":"password","username":"testuser#ibm.com","password":"testuser"}'
HTTP/2 403
date: Tue, 04 Jun 2019 17:20:54 GMT
content-type: text/html; charset=utf-8
set-cookie: __cfduid=d8fb55f6b30555b81f64b3c3e40bbf8f71559668853; expires=Wed, 03-Jun-20 17:20:53 GMT; path=/; domain=.us-south.appid.cloud.ibm.com; HttpOnly
x-dns-prefetch-control: off
x-frame-options: SAMEORIGIN
strict-transport-security: max-age=15552000; includeSubDomains
x-download-options: noopen
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
surrogate-control: no-store
cache-control: no-store, no-cache, must-revalidate, proxy-revalidate
pragma: no-cache
expires: 0
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 4e1b948028aec1cf-IAD
Error - cloud directory is OFF
If I use "grant_type":"client_credentials", it returns get an access token, but I need an identity token so the application can do authorization based on the user.
I've tried using the 'web' version in the ingress definition, and the web redirect works fine. So I know SAML is configured correctly.
You're mixing few different concepts here.
SAML authentication works by presenting a Login UI to user. User needs to fill email/password (or whatever credentials are) and then be taken back to the application. Bottom line here is SAML authentication workflow implies human user that can interact with browser in order to enter credentials. In order to achieve SAML federation through OpenID Connect (the protocol App ID is based on), a grant_type called authorization_code is used. This workflow also implies presenting user with login UI. Since SAML authentication cannot be used without presenting user with a UI you cannot use API only approach in order to authenticate users. With SAML you have to use grant_type=authorization_code, which will only work properly in browsers (unless you do html scraping, which is not recommended).
"grant_type=client_credentials" works differently. It is designed for non-user-interactive scenarios, where you do not have human users involved. SAML is used for authenticating users, client_credentials is used for authenticating applications/services.
Check out the Technologies Under the Hood video in App ID Tutorials on youtube, it explains the differences between various workflows - https://www.youtube.com/playlist?list=PLbAYXkuqwrX2WLQqR0LUtjT77d4hisvfK
I make a POST request to REST API to upload a file. In Postman everything works fine. I add Basic authorization and custom CSRF (XSRF) token which I get from the server.
I want to make the same using cURL. I copied the code from Postman, and it does not seem to work.
I believe that the error is related to CSRF because if I turn off CSRF on server and make the same cURL call without CSRF token, everything works fine.
Now some more details:
That's what the command for cURL which Postman gives:
curl -X POST -H "XSRF: 79f51981-8e85-4e26-be1b-bf63aed92a42" -H "Authorization: Basic bbhjbjb=" -H "Cache-Control: no-cache" -H "Postman-Token: 76a7a43b-f407-15a2-aaff-5242b44d0f47" -H "Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW" -F "package=#C:\Downloads\hello-world.zip" "http://host:port/api/import"
And that's the reply I get with --verbose
timeout on name lookup is not supported
Trying ::1...
Connected to localhost (::1) port 7777 (#0)
POST /api/import HTTP/1.1
Host: localhost:7777
User-Agent: curl/7.47.1
Accept: /
XSRF: 79f51981-8e85-4e26-be1b-bf63aed92a42
Authorization: Basic bbhjbjb=
Cache-Control: no-cache
Postman-Token: 76a7a43b-f407-15a2-aaff-5242b44d0f47
Content-Length: 31281
Expect: 100-continue
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW;
boundary=------------------------742d3475ac5f6aba
< HTTP/1.1 302 Found
< Set-Cookie: JSESSIONID=1qfjmbntrthxll;Path=/api < Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Set-Cookie: XSRF=b29bd143-cc80-49ad-b495-711125678o;Path=/;Expires=Thu, 15-Dec-2016 10:28:46 GMT
< XSRF: b29bd143-cc80-49ad-b495-711125678o < Location:
http://localhost:7777/api/login/error.jsp?errorMessage=Access Denied
< Content-Length: 0
< Server: Jetty(9.2.17.v20160517)
HTTP error before end of send, stop sending
Closing connection 0
I am probably missing something very obvious here, but don't know what yet.
Looks like I am redirected to login page, not being authenticated correctly, but do not know why (I do send XSRF in cURL). I tried also adding sessionid in cURL - also didn't work.
Any ideas and directions about where to search would be very appreciated!!!
As mentioned in this post, add following option
--cookie "csrftoken=XXXXXX;sessionid=YYYYYYY"
along with
-H "X-CSRFToken: XXXXX"
It is unclear how your server side code is implemented. One visible difference can be seen here is the UserAgent string in request header User-Agent: curl/7.47.1. You may try with adding -A "Mozilla/5.0" with your curl request.
About the comment above regarding XSRF 1-time token; Your server is returning Set-Cookie header in response. It can happen that the postman is using that as cookie for second time request, and that's why it works for it over and over. You can try adding -H "Cookie: XSRF=b29bd143-cc80-49ad-b495-711125678o" at the end of your curl and see if that makes any difference.
Those are all wild guess. Better you add some code at your server side that can print the request-headers. Then make two requests, one from curl and other one from postman. After that check the difference between the request headers. That will give you some clue.
In the end it turned out that the session id was required (adding JSESSIONID in cURL solved the problem).
Without more info on the server side code, I'm not sure either. If you're making your call from cURL, and not Postman, do you really need the Postman-Token header? Maybe it will work if you remove -H "Postman-Token: 76a7a43b-f407-15a2-aaff-5242b44d0f47" from the code.
curl -X POST \
-H "XSRF: 79f51981-8e85-4e26-be1b-bf63aed92a42" \
-H "Authorization: Basic bbhjbjb=" \
-H "Cache-Control: no-cache" \
-H "Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW" \
-F "package=#C:\Downloads\hello-world.zip" \
"http://host:port/api/import"
I am using Grails 2.3.8 on a Mac.
I hope to use Grails to quickly develop a RESTful API. I started with the basic documentation for Web Services, found here for my version:
http://grails.org/doc/2.3.8/guide/webServices.html#domainResources
This seems to suggest that I can create a simple Domain Class in Grails, then annotate with the #Resource from grails.rest, as follows (straight from the docs above):
import grails.rest.*
#Resource(uri='/books', formats=['json', 'xml'])
class Book {
String title
static constraints = {
title blank:false
}
}
When I place this file into the grails-app/domain directory and run the app, the docs suggest I should be able to use cURL to add "Book" objects via HTTP:
curl -i -X POST -H "Content-Type: application/json" -d '{"title":"Along Came A Spider"}' localhost:8080/myapp/books
But this gives me HTTP 422, with the following message:
HTTP/1.1 422 Unprocessable Entity
Server: Apache-Coyote/1.1
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
Date: Tue, 05 Aug 2014 01:46:05 GMT
{"errors":[{"object":"Book","field":"title","rejected-value":null,"message":"Property [title] of class [class Book] cannot be null"}]}
Can anyone advise as to what I am missing here? I expected this to be pretty straightforward.
As #raffian mentioned above in comment, this was due to a bug in Grails 2.3.8:
https://jira.grails.org/browse/GRAILS-11399
Upgrading resolved the issue.
Trying to mirror a local intranet site and have found previous questions using 'wget'. It works great with sites that are anonymous, but I have not been able to use it against a site that is expecting username\password (IIS with Integrated Windows Authentication).
Here is what I pass in:
wget -c --http-user='domain\user' --http-password=pwd http://local/site -dv
Here is the debug output (note I replaced some with dummy values obviously):
Setting --verbose (verbose) to 1
DEBUG output created by Wget 1.11.4 on Windows-MSVC.
--2009-07-14 09:39:04-- http://local/site
Host `local' has not issued a general basic challenge.
Resolving local... seconds 0.00, x.x.x.x
Caching local => x.x.x.x
Connecting to local|x.x.x.x|:80... seconds 0.00, connected.
Created socket 1896.
Releasing 0x003e32b0 (new refcount 1).
---request begin---
GET /site/ HTTP/1.0
User-Agent: Wget/1.11.4
Accept: */*
Host: local
Connection: Keep-Alive
---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 401 Access Denied
Server: Microsoft-IIS/5.1
Date: Tue, 14 Jul 2009 13:39:04 GMT
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
Content-Length: 4431
Content-Type: text/html
---response end---
401 Access Denied
Closed fd 1896
Unknown authentication scheme.
Authorization failed.
NTLM authentication is broken in wget 1.11, use 1.10 instead.
Curl is actually probably a better tool for fetching content from NTLM-authenticated web servers. You can get an equivalent function to your proposed wget command line by using:
curl --anyauth --user username:password http://someserver/site
I've seen references to being able to use the NTLM Authorization Proxy Server to get around these types of problems.
use --auth-no-challenge option (wget 1.11+) (it's now considered unsafe)
I found solution.
It is work-around for Basic auth IIS7.
When auth is successeful it send next http header:
'Authorization: < type > < credentials >'.
So we able to do authorization in browser and
copy this header params from browser (firebug addon) or generate:
$ echo -en 'username:password' | base64
dXNlcm5hbWU6cGFzc3dvcmQK
$ echo 'dXNlcm5hbWU6cGFzc3dvcmQK' | base64 -d
username:password
example:
$ wget --header="Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQK" http://example.com/