I've been waiting for a good sync client for OneDrive (15 GB for free!) on Linux, but Microsoft seems to have other plans...
So I've decided to write my own, using D. Take a look:

  http://skilion.github.io/onedrive/

On 23/09/15 8:43 AM, skilion wrote:
> I've been waiting for a good sync client for OneDrive (15 GB for free!)
> on Linux, but Microsoft seems to have other plans...
> So I've decided to write my own, using D. Take a look:
>
>    http://skilion.github.io/onedrive/

You probably should not be exposing developer information for authentication.
You need to get the authentication fixed. Users should login via user/pass.

Once that is done, get that on Reddit! It is awesome!

On Wednesday, 23 September 2015 at 04:30:23 UTC, Rikki Cattermole wrote:
> You probably should not be exposing developer information for authentication.
> You need to get the authentication fixed. Users should login via user/pass.

I think you are referreing to the the fields client_id and client_secret in the config file.

As I understand it, if a service is using OAtuh2, it is exactly to allow its users to use third party apps without leaking the username and password. My app is registered as a desktop application, so it should be assumed that the client "secret" can't be really kept secret like in a web app.

Knowing the client secret allows you to produce API calls under my app name, but you still need to get a permission from the user to access their data.

Problem is right now anyone can make an app and pretend its your app, and then ...

If the user gives your keys access to their stuff so does anyone else who has your keys, if they can get the oauth2 redirect to redirect to a matching url at least.

On Wed, Sep 23, 2015 at 10:38 AM, skilion via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> On Wednesday, 23 September 2015 at 04:30:23 UTC, Rikki Cattermole wrote:
>
>> You probably should not be exposing developer information for
>> authentication.
>> You need to get the authentication fixed. Users should login via
>> user/pass.
>>
>
> I think you are referreing to the the fields client_id and client_secret in the config file.
>
> As I understand it, if a service is using OAtuh2, it is exactly to allow its users to use third party apps without leaking the username and password. My app is registered as a desktop application, so it should be assumed that the client "secret" can't be really kept secret like in a web app.
>
> Knowing the client secret allows you to produce API calls under my app name, but you still need to get a permission from the user to access their data.
>
>

I think this should be on reddit either way. Perhaps someone will suggest a
way around the oauth2 limitation.
Having to generate new client secrets just to use an app that already
exists seems like a mission, so providing a default set that work and the
user can just make sure they get the original app seems more practical.
i.e. download binary from a reputable place i.e. your distributions repos.

Also you are doing the same way everyone else does it; by prompting at the command line sooo....




On Wed, Sep 23, 2015 at 2:38 PM, Rory McGuire <rjmcguire@gmail.com> wrote:

> Problem is right now anyone can make an app and pretend its your app, and then ...
>
> If the user gives your keys access to their stuff so does anyone else who has your keys, if they can get the oauth2 redirect to redirect to a matching url at least.
>
> On Wed, Sep 23, 2015 at 10:38 AM, skilion via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:
>
>> On Wednesday, 23 September 2015 at 04:30:23 UTC, Rikki Cattermole wrote:
>>
>>> You probably should not be exposing developer information for
>>> authentication.
>>> You need to get the authentication fixed. Users should login via
>>> user/pass.
>>>
>>
>> I think you are referreing to the the fields client_id and client_secret in the config file.
>>
>> As I understand it, if a service is using OAtuh2, it is exactly to allow its users to use third party apps without leaking the username and password. My app is registered as a desktop application, so it should be assumed that the client "secret" can't be really kept secret like in a web app.
>>
>> Knowing the client secret allows you to produce API calls under my app name, but you still need to get a permission from the user to access their data.
>>
>>
>

On 09/23/2015 08:38 AM, Rory McGuire via Digitalmars-d-announce wrote:
> Problem is right now anyone can make an app and pretend its your app, and
> then ...
>
> If the user gives your keys access to their stuff so does anyone else who
> has your keys, if they can get the oauth2 redirect to redirect to a
> matching url at least.
>

Isn't oauth/openid just kindof a big bundle of such phishing problems anyway?

On Wednesday, 23 September 2015 at 13:01:54 UTC, Rory McGuire wrote:
> I think this should be on reddit either way. Perhaps someone will suggest a
> way around the oauth2 limitation.
> Having to generate new client secrets just to use an app that already
> exists seems like a mission, so providing a default set that work and the
> user can just make sure they get the original app seems more practical.
> i.e. download binary from a reputable place i.e. your distributions repos.
>
> Also you are doing the same way everyone else does it; by prompting at the command line sooo....
>


I don't know to much about oauth2, but could we in theory add a layer of security by only allowing some client id that has a sort of checksum based on the source code of the application? I don't know how client ids are generated, but its just a thought.

I can't think of a way to do phishing with oauth2, doesn't mean it can't be done somehow :)

Basically because you have to configure the redirect when you setup the client_secret the server will only ever send the browser to that redirect, a mismatch of requested redirect will just cause an error on Google Apps for example.

Lets say this app has a redirect to localhost:1234/oauth set up during
credentials creation on the oauth server.
Then if you could get some malicious code to run at that host:port then you
could get the access token that the oauth server would think it is sending
to this app.

So yes letting everyone know your client_secret is dodgy, but actually getting hacked because of it seems highly unlikely.


On Wed, Sep 23, 2015 at 4:51 PM, Nick Sabalausky via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:

> On 09/23/2015 08:38 AM, Rory McGuire via Digitalmars-d-announce wrote:
>
>> Problem is right now anyone can make an app and pretend its your app, and then ...
>>
>> If the user gives your keys access to their stuff so does anyone else who has your keys, if they can get the oauth2 redirect to redirect to a matching url at least.
>>
>>
> Isn't oauth/openid just kindof a big bundle of such phishing problems anyway?
>
>

The client id is generated on oauth server when setting up credentials for an app / webservice.

You could never trust an app checksum because you would never know if it was fake. (Also this would only be something you could consider if you were implementing an oauth server or you had some intermediate server)

On Thu, Sep 24, 2015 at 2:53 AM, Charles via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> On Wednesday, 23 September 2015 at 13:01:54 UTC, Rory McGuire wrote:
>
>> I think this should be on reddit either way. Perhaps someone will suggest
>> a
>> way around the oauth2 limitation.
>> Having to generate new client secrets just to use an app that already
>> exists seems like a mission, so providing a default set that work and the
>> user can just make sure they get the original app seems more practical.
>> i.e. download binary from a reputable place i.e. your distributions repos.
>>
>> Also you are doing the same way everyone else does it; by prompting at the command line sooo....
>>
>>
>
> I don't know to much about oauth2, but could we in theory add a layer of security by only allowing some client id that has a sort of checksum based on the source code of the application? I don't know how client ids are generated, but its just a thought.
>
>

On Tuesday, 22 September 2015 at 20:43:32 UTC, skilion wrote:
> I've been waiting for a good sync client for OneDrive (15 GB for free!) on Linux, but Microsoft seems to have other plans...
> So I've decided to write my own, using D. Take a look:
>
>   http://skilion.github.io/onedrive/


What this string in config.d do?
 auto r = regex("(?:^\\s*)(\\w+)(?:\\s*=\\s*\")(.*)(?:\"\\s*$)");