Re: Serializing and abstract classes

[Jani Tiainen]

Hi.

You're using table inheritance which by default is like one way road.

In Question model there exists two reverse relations to your child models.
You just need to test which one is set.

If you truly want abstract base class (which changes model layouts as well)
you need to make Question model abstract in Meta.


to 19. syysk. 2019 klo 0.20 Courtney Bracefield <
courtneybracefiel...@gmail.com> kirjoitti:

> Hi there,
>
> I have some classes in my model.py file shown below. I would like my API
> to return a list of questions showing the slug, title and question_type of
> each question. Fetching the slug and title is trivial, but I cannot for the
> life of me access the question_type of a question because it isn't under
> the Question class, it is a field under each subclass (shown below).
>
> Anyone have any ideas? Thanks!
>
> class Question(TranslatableModel):
> """Base class for a question.
>
> Aims to be an abstract class as questions should be
> a particular subtype, though the class is not made
> completely abstract to allow retrieving all child
> objects through the InheritanceManager.
> """
>
> slug = models.SlugField(unique=True)
> title = models.CharField(max_length=SMALL)
> objects = InheritanceManager()
>
>
> class QuestionTypeProgram(Question):
> """A program based question."""
>
> QUESTION_TYPE = 'program'
>
>
> class QuestionTypeFunction(Question):
> """A function based question."""
>
> QUESTION_TYPE = 'function'
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-rest-framework+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-rest-framework/6da5f79c-5a51-4fe5-aa34-64a96b3571b6%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-rest-framework/CAHn91odLS0A-1fdtkpe0HBEGzRsrwH-6wZ%3Dv7bbajSg96-XjGA%40mail.gmail.com.

Re: Documentation for "Tutorial 1: Serialization" need to another version for Windows OS

[Jani Tiainen]

Hi.

You might want to checkout pipenv tool. It handles nicely both virtualenv
and package installation.


ma 11. maalisk. 2019 klo 13.39 Edely Gomes  kirjoitti:

> Hey, Trong.
>
> About your virtual environment, in Windows usualy you activate the env
> with a command like
>
> .\env\Scripts\activate
>
> No need for `python -m source`
>
> If you are using Linux, you would do
>
> source /env/bin/activate
>
> Are you sure you are activating your environment?
>
> Em domingo, 10 de fevereiro de 2019 11:09:19 UTC-3, trong vo nhu escreveu:
>>
>> Hi everyone ‍♂️,
>>
>> I'm a newbie of Python and Django framework. While learning with tutorial
>> in www.django-rest-framework.org, I experienced with many promblems
>> because I am using Windows OS.
>> I tried to find the feedback button for the documentation update and
>> didn't find it.
>> So I want to know where can I give the feedback for those issue, in my
>> case they are corresponding commands with Windows OS.
>>
>> Example: in this tutorial Tutorial 1: Serialization
>> 
>> These two commands:
>> virtualenv env
>> source env/bin/activate
>> should be (I'm using python 3.7 64bit, Windows 10):
>> python -m source env\Scripts\activate
>> env\Scripts\activate
>>
>> Sorry for my bad English.
>> Thank you very much.
>> Trong
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-rest-framework+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Get user password from JWT

[Jani Tiainen]

Hi.

Note that JWT is not encryption but cryptography signing. So password would
be in clear plaintext in JWT payload. Also storing password in session
might not be a good thing depending where your sessions are stored since
again, password would be plain text there as well.

If you really need to use plain text password storing a secondary "I don't
care what happens with this password" would be better solution to access
remote services.


On Fri, Jan 18, 2019 at 2:33 AM Wandss  wrote:

> Hi everyone,
>
> I'd like to know if anyone could point me to a solution to a problem that
> seems to be easy.
>
> I've built an API and I'm authenticating users with djangorest_jwt.
> After user has been authenticated, I'll have to "programmatcially" consume
> another API which I connect with requests using BasicAuthentication,
> meaning I'll have to pass to this other API the users's plain text password.
>
> Using only Django I could store user's password into a session variable
> and retrieve it later on any other view.
>
> How could I solve this situation without sessions?
> Has anyone ever experienced this situation?
>
> Regards you all and
> Happy coding !!!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-rest-framework+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Jani Tiainen

- Well planned is half done, and a half done has been sufficient before...

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Information

[Jani Tiainen]

Hi.

Before jumping into more advanced stuff, what problem you do have that DRF
would resolve for you?

Because building a dashboard like that doesn't require DRF, you can do it
very well with Django itself without any additional packages.

Also what do you mean with "authentication in a secure way"? What would be
insecure?

On Tue, Jan 8, 2019 at 12:08 PM  wrote:

> Hello, I started in Django and I would like to know if Django REST
> framework could meet my needs:
>
>
>- Manages authentication in a secure way (admin & user) ?
>- Have a vertical dashboard as on this image (user & admin, of course
>the admin will have more functionality) ?
>
> [image: 2019-01-07_16h17_25-ConvertImage.jpg]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Or better to go on another package of its kind django-control
> <https://django-controlcenter.readthedocs.io/en/latest/> ?
>
> Thank you, you would help me a lot by answering it is question. :)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-rest-framework+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Jani Tiainen

- Well planned is half done, and a half done has been sufficient before...

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Authentication for Anonymous users

[Jani Tiainen]

Hi,

Sure you could but use would be that? It's just a string describing user
agent. And it may be a lie.

You do have a few options here:

Simplest is that you really don't care about "anonymous" access or it's
usage limits. You may impose some throttling to avoid hammering of your
service.

Another option is to use a long term session to store number of accesses
and don't care about people who reset their sessions.

Finally you can make people to login with some "simple" authorization
mechanism like social site logins.


On Fri, Apr 20, 2018 at 3:23 PM, Musharaf Baig <musharaf...@gmail.com>
wrote:

> Can we make authentication on User-Agent coming in request?
>
> On Friday, April 20, 2018 at 3:36:45 PM UTC+5, Jani Tiainen wrote:
>>
>> Hi,
>>
>> 1) How you control that user (without login) has expire his/her
>> number/time on your site?
>>
>> 2) Have users (internal, even you don't have registration or login) that
>> you assign permanent token and use it as an auth. Django Rest Framework
>> supports it out of the box.
>>
>> On Thu, Apr 19, 2018 at 10:43 PM, Musharaf Baig <musha...@gmail.com>
>> wrote:
>>
>>> I *do not* have register/login mechanism for the users.
>>>
>>> I need two types of authentication:
>>>
>>>1.
>>>
>>>To make it available I would like to let the user use it for free
>>>with a limited number of call s or time
>>>
>>> - for example after the API is called 50 times, I would like that the
>>> token expires. An alternative solution is that  the token should expire in
>>> 2 days.
>>>
>>> 2) An authentication with a key that does not expire at all.
>>>
>>> Is it possible? Need suggestions. Thanks
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django REST framework" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-rest-framework+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Jani Tiainen
>>
>> - Well planned is half done, and a half done has been sufficient before...
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-rest-framework+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Jani Tiainen

- Well planned is half done, and a half done has been sufficient before...

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to not allow additional properties

[Jani Tiainen]

Hi,

Is there a reason you want to reject requests with extra data rather than
just ignore extra values?

One way to do that could be whitelisting allowed params per view but that
you have to do yourself. You could probably use DRF authentication API for
that.

15.1.2018 18.43 "Daniel Chimeno"  kirjoitti:

> Hello!
>
> How could I deny requests that has additional properties?
> Example:
>
> class IntervalSerializer(serializers.Serializer):
> month = serializers.DateField(format='%Y-%m', input_formats=['%Y-%m'])
> day_of_week = serializers.IntegerField(min_value=1, max_value=7)
> start_hour = serializers.IntegerField(min_value=0, max_value=24)
> end_hour = serializers.IntegerField(min_value=1, max_value=24)
>
> I would like to allow incoming requests like:
> {'month': '2017-03', 'day_of_week': 7, 'start_hour': 3, 'end_hour': 2}
>
>
> but to not allow incoming requestse like:
> {'month': '2017-03', 'day_of_week': 7, 'start_hour': 3, 'end_hour': 2,
> 'another_attribute': 3}
>
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-rest-framework+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Current I18n strategy seems awfully fragile

[Jani Tiainen]

Hi,

This is how things are done with gettext [1] in general and Django (and 
pretty much it's whole ecosystem) just has adopted that convention.


Having abstract keys instead of plain English isn't problem free either, 
they just have a different problems.


Note that you can have Django gettext contextual markers to avoid 
translation collisions in your translations. [2]


1. 
https://www.gnu.org/software/gettext/manual/html_node/Preparing-Strings.html#Preparing-Strings
2. 
https://docs.djangoproject.com/en/1.11/topics/i18n/translation/#contextual-markers


On 2.11.2017 12.45, Steve Jorgensen wrote:
Well, convention or not, can you see why that is a ridiculously 
fragile convention? From what you're saying, this is how things are 
done in Django-land though, so it would be awkward for DRF to do 
something different. Poop. :(


On Wednesday, November 1, 2017 at 11:16:26 PM UTC-7, Jani Tiainen wrote:

Hi,

Django and DRF both uses GNU gettext to handle translations. With
gettext it's convention is to use plain English "message id"
instead of what Ruby does.

Ruby seems to have it's own translation mechanisms which is
tailored to be used with abstract message id's.

2.11.2017 2.23 "Steve Jorgensen" <stev...@gmail.com >
kirjoitti:

Looking at
http://www.django-rest-framework.org/topics/internationalization/
<http://www.django-rest-framework.org/topics/internationalization/>
and

https://raw.githubusercontent.com/encode/django-rest-framework/master/rest_framework/locale/en_US/LC_MESSAGES/django.po

<https://raw.githubusercontent.com/encode/django-rest-framework/master/rest_framework/locale/en_US/LC_MESSAGES/django.po>


I see that each msgid value is a full English language
message. That means that if an application has its own
translation(s) for DRF's intrinsic messages, they can break if
the wording of the messages changes from one DRF to the next.
I come from the Rails world where the IDs are symbols that do
not change, and the actual text for the message in any
language is determined through I18n.
Is there some way this could be improved in future versions of
DRF?
-- 
You received this message because you are subscribed to the

Google Groups "Django REST framework" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to
django-rest-framework+unsubscr...@googlegroups.com .
For more options, visit https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.

--
You received this message because you are subscribed to the Google 
Groups "Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to django-rest-framework+unsubscr...@googlegroups.com 
<mailto:django-rest-framework+unsubscr...@googlegroups.com>.

For more options, visit https://groups.google.com/d/optout.


--
Jani Tiainen

--
You received this message because you are subscribed to the Google Groups "Django 
REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Current I18n strategy seems awfully fragile

[Jani Tiainen]

Hi,

Django and DRF both uses GNU gettext to handle translations. With gettext
it's convention is to use plain English "message id" instead of what Ruby
does.

Ruby seems to have it's own translation mechanisms which is tailored to be
used with abstract message id's.

2.11.2017 2.23 "Steve Jorgensen"  kirjoitti:

> Looking at http://www.django-rest-framework.org/topics/
> internationalization/ and https://raw.githubusercontent.com/encode/
> django-rest-framework/master/rest_framework/locale/en_US/
> LC_MESSAGES/django.po
>
> I see that each msgid value is a full English language message. That
> means that if an application has its own translation(s) for DRF's intrinsic
> messages, they can break if the wording of the messages changes from one
> DRF to the next.
>
> I come from the Rails world where the IDs are symbols that do not change,
> and the actual text for the message in any language is determined through
> I18n.
>
> Is there some way this could be improved in future versions of DRF?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-rest-framework+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How can I raise custom Exception in validate

[Jani Tiainen]

Hi,

To me it looks like you're doing wrong solution for your problem.

Serializer is mainly meant to convert data from complex format to python 
primitives and vice versa.


Validation is to make sure that converted (deserialized) object matches 
the definition of the serializer.


Now, to me it looks like you want to check is something authenticated. 
That's not exactly job for serializer,
but job of your view code (one that calls deserialization) after object 
has been successfully deserialized and validated.



On 12.06.2017 13:30, Sinan Ülker wrote:
Is there any example of custom handling in serializer. I couldn't 
figure out how to do that.


On Jun 12, 2017 09:19, "Jani Tiainen" <rede...@gmail.com 
<mailto:rede...@gmail.com>> wrote:


Hi,

You need to raise validation error (or subclass of it).

Another option is to move authentication check outside serializer
(which might be right thing to do)
and catch that error properly there (or do custom handling).


On 12.06.2017 04:57, Sinan Ülker wrote:

Hello,

Since serializer.is_valid()  does not catch the Exceptions other
than the validationError, how can i raise custom exceptions in
validate method and then catch get them with serializer.errors

for example:

class  Foo(serializers.Serializer):
 def  validate(self,data):
 raise  exceptions.AuthenticationFailed("message")
 then I want to test it like this but serializer.is_valid()
line always return error.
serializer = Foo(some.data)
is_valid = serializer.is_valid()
expected_error = {['message.']}
self.assertFalse(is_valid)
self.assertEqual(serializer.errors, expected_error)

I also could not figure out how to handle it with custom
exception handler can you help me about this. I also appreciate
if you supply some examples

-- You received this message because you are subscribed to the
Google Groups "Django REST framework" group. To unsubscribe from
this group and stop receiving emails from it, send an email to
django-rest-framework+unsubscr...@googlegroups.com
<mailto:django-rest-framework+unsubscr...@googlegroups.com>. For
more options, visit https://groups.google.com/d/optout
<https://groups.google.com/d/optout>. 


-- 
Jani Tiainen


-- You received this message because you are subscribed to a topic
in the Google Groups "Django REST framework" group. To unsubscribe
from this topic, visit

https://groups.google.com/d/topic/django-rest-framework/8Ai8Vrss0Gg/unsubscribe

<https://groups.google.com/d/topic/django-rest-framework/8Ai8Vrss0Gg/unsubscribe>.
To unsubscribe from this group and all its topics, send an email
to django-rest-framework+unsubscr...@googlegroups.com
<mailto:django-rest-framework+unsubscr...@googlegroups.com>. For
more options, visit https://groups.google.com/d/optout
<https://groups.google.com/d/optout>. 

-- You received this message because you are subscribed to the Google 
Groups "Django REST framework" group. To unsubscribe from this group 
and stop receiving emails from it, send an email to 
django-rest-framework+unsubscr...@googlegroups.com 
<mailto:django-rest-framework+unsubscr...@googlegroups.com>. For more 
options, visit https://groups.google.com/d/optout. 

--
Jani Tiainen

--
You received this message because you are subscribed to the Google Groups "Django 
REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How can I raise custom Exception in validate

[Jani Tiainen]

Hi,

You need to raise validation error (or subclass of it).

Another option is to move authentication check outside serializer (which 
might be right thing to do)

and catch that error properly there (or do custom handling).


On 12.06.2017 04:57, Sinan Ülker wrote:

Hello,

Since serializer.is_valid()  does not catch the Exceptions other than 
the validationError, how can i raise custom exceptions in validate 
method and then catch get them with serializer.errors


for example:

class  Foo(serializers.Serializer):
 def  validate(self,data):
 raise  exceptions.AuthenticationFailed("message")
 then I want to test it like this but serializer.is_valid() line 
always return error.

serializer = Foo(some.data)
is_valid = serializer.is_valid()
expected_error = {['message.']}
self.assertFalse(is_valid)
self.assertEqual(serializer.errors, expected_error)



I also could not figure out how to handle it with custom exception 
handler can you help me about this. I also appreciate if you supply 
some examples





--
You received this message because you are subscribed to the Google 
Groups "Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to django-rest-framework+unsubscr...@googlegroups.com 
<mailto:django-rest-framework+unsubscr...@googlegroups.com>.

For more options, visit https://groups.google.com/d/optout.


--
Jani Tiainen

--
You received this message because you are subscribed to the Google Groups "Django 
REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django rest framework request data is always null

[Jani Tiainen]

Hi,

Looks like your code that calls POST data is incorrect. As you see in 
printout for some reason included data is strangely wrapped as an object 
to toplevel item_id.



On 10.03.2017 15:27, Sandesh Naroju wrote:
I just want to try simple Django rest framework code, I used APIVIEW 
and posted data through browser.


CODE:

class GetData(APIView):

def post(self, request, format=None):
if request.method == 'POST':
item_id = request.data.get('item_id')
return Response({"return": "OK ","item_id":item_id})
else:
return Response({"return": "NOT OK "})


The above code should echo the item_id whatever i "POST"ed. but the 
result is always null.


POST data:

{
 "item_id" : "3456787"
}

result:

{
"item_id":null,
"return" :"OK "
}

I don't understand where I went wrong. the above code works fine in my 
loaclhost but does not work in production server.


I tried to print request.data which gives me this

{ "item_id": { "_content_type": "application/json", "_content": 
"{\r\n\r\n\"item_id\" : \"3456787\"\r\n\r\n}" }, "return": "OK " }


--
You received this message because you are subscribed to the Google 
Groups "Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to django-rest-framework+unsubscr...@googlegroups.com 
<mailto:django-rest-framework+unsubscr...@googlegroups.com>.

For more options, visit https://groups.google.com/d/optout.


--
Jani Tiainen

--
You received this message because you are subscribed to the Google Groups "Django 
REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Apps aren't loaded yet, from rest_framework.authtoken.models import Token

[Jani Tiainen]

Hi,

Don't import models in models.py since at point of import there is no 
guarantee that model is actually registered, and thus you get the exception.



To fix the issue use string format to refer models in other apps. In 
your case instead of importing model and doing the following:


token = models.ForeignKey(Token)

You should do (check app name, I just guessed it):

token = models.ForeignKey('authtoken.Token')

(and remove the import all thogether)

On 30.01.2017 10:50, Soham Navadiya wrote:


I have upgraded django 1.7 to 1.9.12 and django-rest-framework 3.5.3

I am getting below error stack after running the server.
I have tried to apply various thing. but It doesn't help.
How can I solve this?

|File "/home/soham/Documents/upg/rest_api/api/models.py", line 7, in 
 from rest_framework.authtoken.models import Token File 
"/home/soham/Documents/upg/rest_api/cubii_d_u/local/lib/python2.7/site-packages/rest_framework/authtoken/models.py", 
line 11, in  class Token(models.Model): File 
"/home/soham/Documents/upg/rest_api/cubii_d_u/local/lib/python2.7/site-packages/django/db/models/base.py", 
line 94, in __new__ app_config = 
apps.get_containing_app_config(module) File 
"/home/soham/Documents/upg/rest_api/cubii_d_u/local/lib/python2.7/site-packages/django/apps/registry.py", 
line 239, in get_containing_app_config self.check_apps_ready() File 
"/home/soham/Documents/upg/rest_api/cubii_d_u/local/lib/python2.7/site-packages/django/apps/registry.py", 
line 124, in check_apps_ready raise AppRegistryNotReady("Apps aren't 
loaded yet.") django.core.exceptions.AppRegistryNotReady: Apps aren't 
loaded yet.|

--
You received this message because you are subscribed to the Google 
Groups "Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to django-rest-framework+unsubscr...@googlegroups.com 
<mailto:django-rest-framework+unsubscr...@googlegroups.com>.

For more options, visit https://groups.google.com/d/optout.


--
Jani Tiainen

--
You received this message because you are subscribed to the Google Groups "Django 
REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Newbie: how to debug POST server response 403?

[Jani Tiainen]

Hi,

Have you checked from your browser debugging tools (network tab or similar)
what's the body of the response? it should tell more detailed reason of an
error.

Convenient place would be views dispatch() method where most of the magic
happens, though usually it's enough to check response body in browser,

My educated guess is that you're missing CSRF token when doing POST.

On Wed, Jan 25, 2017 at 4:39 PM, Bob Aalsma <overhaalsgang.24@gmail.com>
wrote:

> Hi,
>
> I'm new to Django Rest Framework (and new to Javascript), not new to
> Python, not really now to Django.
>
> I've created a Javascript that should send a POST request to
> localhost/Django Rest framework app.
>
> I've copied the contents of the message from Javascript console.log into
> the Rest API html - OK
> I've copied the message to a POST through http - OK:
>
> HTTP/1.0 201 Created
>
> BUT when I send the POST from the Javascript to the server, it says
>
> "POST /texts/texts/ HTTP/1.1" 403 58
>
> So I'd want to get a closer look at what happens with the incoming message
> and I'd normally put a "import ipdb; ipdb.set_trace()" at a convenient
> place.
> And now I discover that I still don't understand enough of this framework
> to decide on "a convenient place"...
> Please help.
>
> Regards,
> Bob
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-rest-framework+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Jani Tiainen

- Well planned is half done, and a half done has been sufficient before...

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.