paul at churchley.org
Tue Jan 14 16:50:19 HKT 2014
Thanks for taking the time to explain Mark.
I'd love to help with OAUTH if I can. I will need a copy of the drupal
site. I will need to set up a development version of the site on my own
server to work on.
I will start to read up on OAUTH now!
On 14 January 2014 01:06, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> For github, I find there are just 3 key concepts to understand. They are
> kind-of counter-intuitive, but once you grasp these you'll understand it
> 1. You will be used to working with centralised repositories, where
> people checkout stuff, make changes, and commit it back. Github doesn't
> work that way. It is not really centralised, and everyone works on their
> own. So, if you want to get stuff from a repository that you want to be
> able to change, the trick is to fork the repository. That makes a copy in
> your own github account that you can work from. Now, there are two
> repositories for the same code (yours and the place you forked from). (P.S.
> If you just want to get stuff but not change it, then "clone" is fine.)
> 2. The second strange thing about git (and github) is that when you
> get a local copy of the repository, you are getting the _entire_
> repository, including the history of all changes to it from day zero. With
> something like svn/cvs, you would just get a specific revision, but with
> git, you get the whole thing. The disadvantage is space and bandwidth. The
> advantage is that you can do all your revision control work locally
> (commit, revert, log, switch branches, etc) without Internet connectivity.
> Clone the OVMS repository, and work on it for a long plane flight -
> including committing changes, working with branches, etc. Once you are back
> in civilisation, you can synchronise your local changes with the repository
> it is cloned from (so long as you have write access - which you will as you
> are just working on your own forked version of the repository).
> 3. The third thing just follows on from the first two. Pushing and
> Pulling. You will be making changes to your local forked copy of the
> repository, but at some time you are going to want to synchronise with the
> upstream version you originally forked from. To pull in changes made
> upstream since you forked, you just pull/merge in the master repository you
> originally forked from) - in general you should do this often, to stay up
> to date and to reduce the chances of conflict with local changes you are
> making. To contribute back to the master repository, you send a pull
> request to the maintainers of the master repository (for the OVMS vehicle
> firmware there are 3 currently). The maintainers will review your changes,
> and if all is ok merge them into the master repository.
> From the coding point of view, I really want to sort out the HTTP API, but
> that means getting OAUTH working. It would be great if you have time to
> help with this - but I guess it is new to both of us. From the perl point
> of view, I can handle it. The issue I have is the overall framework and
> getting an OAUTH server working in PHP under drupal www.openvehicles.com.
> What we need is:
> 1. The user App goes to www.openvehicles.com for authentication. He
> logs in, and the server presents him with a list of permissions (e.g.; read
> gps location, read historical data, read battery status, etc) that the user
> can give the app. The result is an authentication blob that goes back to
> the App. This is PHP code in drupal.
> 2. The App then goes to the api, presents the authentication blob,
> which the api server then validates and returns a security token. This is
> perl code in the OVMS perl server.
> 3. The App then goes to the api, presents the token, and gets the data
> requested. This is perl code in the OVMS perl server.
> 4. We need an Apps screen on the www.openvehicles.com server, which
> shows the user which Apps he has authorised, and allows him to revoke those
> This is standard OAUTH, and if we follow the standard, client side Apps
> will be easier (using standard libraries) and it will be simpler to work
> with third parties (such as IFTTT). The issue is that the coding of OAUTH
> servers seems very poorly documented, in either PERL or PHP/drupal.
> Once we've got the authentication framework resolved, finalising the API
> should be relatively simple. It would be great if you can help with the
> OAUTH stuff in PHP+drupal.
> Regards, Mark.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OvmsDev