Not a bad idea, actually, but the other site is on shared hosting, so
I don't expect the host to be willing to add a self-signed cert as
trusted.
On May 24, 10:07 am, Alex Robbins <alexander.j.robb...@gmail.com>
wrote:
> Just a thought, but if you are the only person using the url, you
> could make your own self-signed security cert. It would be free and
> protect your data. It won't show up as trusted to users, but your
> other server can be set to accept it. (Assuming the lack of ssl is a
> budget issue, that wouldn't fix a technical issue.)
>
> Alex
>
> On May 23, 10:10 am, ringemup <ringe...@gmail.com> wrote:
>
>
>
> > Hi folks --
>
> > I'm putting together a simple API to allow a separately-hosted but
> > trusted site to perform a very limited set of actions on my site. I'm
> > wondering whether the design I've come up with is reasonably secure:
>
> > - Other site gets an API key, which is actually in two parts, public
> > key and private key, each of which is a uuid generated by Python's
> > uuid module.
>
> > - The API key object in the DB references a User object, whose
> > permissions determine what actions the API key owner may take
>
> > - Other site submits a POST request to a special URL on my site. POST
> > request contains 3 vars: public_key, data (as JSON), hash.
>
> > - Hash is a SHA1 of the data concatenated with the private key
>
> > - I use the public key to search the database for the API key and
> > permissions.
>
> > - I generate the SHA1 of the data concatenated with the private key
> > from the DB, and check it against the submitted hash; only if they
> > match do I decode the data dict and take the actions specified within
>
> > - I then return an HTTP response containing a JSON object of the
> > format:
>
> > {
> > return_data: [object containing success / failure codes, messages,
> > any other data],
> > hash: [SHA1 of return_data concatenated with private key]
>
> > }
>
> > - All data will be transmitted in the clear (no SSL currently
> > available -- *sigh*), but there will be no sensitive data in the
> > incoming data dict. return_data may contain values that aren't meant
> > to be broadcasted, but aren't really sensitive (along the lines of
> > activation keys for a game)
>
> > Do you see any major potential flaws in this plan?
>
> > Thanks!
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django users" group.
> > To post to this group, send email to django-us...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-users+unsubscr...@googlegroups.com.
> > For more options, visit this group
> > athttp://groups.google.com/group/django-users?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group
> athttp://groups.google.com/group/django-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
