Hi all,
How do folks --and the site's owner-- feel about native mobile clients for the website? let's say, for the review functionality at least. Maybe users who are devs can contribute? the review process appears to be service based so it looks doable.
Myself I'm an Android user but an iOS dev.
Thoughts?

[ファブリス]

I'd love to see some native mobile client for the review functionality.

In theory you can do a native front end for the flashcard reviews, but it would be limited if it relies only on the "ajax" calls. So I think the site needs a proper API, and I think some kind of private key in the user accounts that they can link to the mobile app, to authenticate themselves.

And then it would need some "syncing" functionality, so the user can review offline, and then sync their progress when they connect.

If someone's motivated enough to brainstorm the API while they build some mockup/simplified version of the client, then I will implement the API. I would otherwise rather continue with incremental improvements to the site.

There was one person who was quite motivated a couple years ago or so and willing to help me out but I was completely unmotivated then, and didn't follw up, so that is entirely my fault.

ps: I suppose, if you are sufficiently motivated, you can already build a functional mockup, that you login within a webview to have the cookies, and then work with the ajax responses from the "free review" modes (I can always document these if needed, though I think the JSON format is pretty self explanatory). If you have a client that can run the free reviews, show the example words, kanji, etc, flip the card functionality etc.. then the SRS is just a matter of adding the API, which is really the smallest part of the work. Creating a functional front end with a nice UI is a lot of work...

Good to hear...
Well the thing is right now I would be mostly interested in having an Android client, and though I'm pretty much a versatile developer I never got around to learn enough Android. So if I do get to learn it as to feel confident starting an Android project, that will mean I'm motivated . Cannot make promises at this point!
I agree about the sync functionality, something like that was on my mind.
Can you give me an idea of the limitations the current ajax interface would have for a native app?

[ファブリス]

Well there is no authentication API. So you have to login through some kind of webkit view, which sets the "logged in cookie and the php session cookies etc", then these would have to be attached to the http requests, then the site will not see the difference whether its a client browser or an app.

I know it's possible to get cookies like that in an app, both iOS and Android. You can also design a native app that actually uses web views (html, css ,javascript), but with the ability to hook native code to the DOM events. I don't know how that works in detail though.

The better way to do it that the site doesn't have yet, is that the site gives a private key in the user settings. Your app takes the private key and username, and gives them along the http requests to authenticate the user. That also means the user doesn't need to enter their Kanji Koohii password to login in the app.

You could add OAuth if you had the time. There are quite a few libs out there that do most of the heavy lifting. OAuth 1 might be easier to put into place, though I personally like dealing with 2.0 better.

OK I haven't inspected much the network traffic while using the site, but my initial thoughts were that what you describe first could work (getting the session cookie and attaching it on every request), and that it wouldn't really matter for the site to see what kind of client it's talking to. I might be missing something though.

[ファブリス]

vix86 Wrote:You could add OAuth if you had the time. There are quite a few libs out there that do most of the heavy lifting. OAuth 1 might be easier to put into place, though I personally like dealing with 2.0 better.

Anyone knows some good tutorial for OAuth with php ? I still haven't found a good "plain english" one. Seems like every tutorial I find tells you how to call a library and/or skims over many parts.

An API is underway and I need to add OAuth soon. Actually the main thing I need is:

- let the user authenticate to the site from within the app without revealing password to the app


Actually I don't want nor need the added complexity of managing access to the user's account from individual apps.

Only the app author needs an API key (and a secret to prevent misuse of the api key etc), I don't want the app user to have to go through more loops enabling apps and whatnot in their settings. I just want them to sign in, and for a time, let the app interface with their account. From what I understand with the tokens, the app is automatically disabled after the token timed out anyway (much like php sessions).

Is a library out of the question? Honestly, I wouldn't try hand rolling your own server side OAuth. I haven't looked into it but I would imagine the keys you give devs are generated from PGP/Public Key encryption.

The basics of OAuth client side are basically,
1) Get an authorization code by directing the user to authorize the app. Include app_id and redirect_url.
2) Give the server the auth code + App id + App secret.
3) Get access_token and refresh_token back.
4) Use access_token to on specified REST endpoints to get user data.

I would imagine server side would look something like.
1) Check redirect url matches app_id. Combine a timestamp and the app_id and encrypt using a server side private key to get an auth code. Redirect the user to the redirect url.
2) Take the auth code and decrypt to get the timestamp and app id. Confirm the supplied app id and secret match whats on file.
3) Generate an access token by combining a timestamp, the app secret, and maybe some other random identifier constant. Encrypt with server private key, app id, and maybe a salt? The refresh token is the same but use a different identifier so you can verify its a refresh token and not something else.
4) When you receive requests, simply decrypt the access token with your private key and verify access token is still valid and everything matches.

EDIT: The access/refresh token will also have a user id encrypted as well; something that lets you know what token goes to what user.

Mind you I've never read the actual specs on OAuth2, but I'd guess it works something like this. The encryption part is generally why you'd want a library. The libraries will just simplify all the heavy lifting of generating what you need.

[ファブリス]

No I will use a library. Thanks.

Best option I've seen so far is http://bshaffer.github.io/oauth2-server-.../cookbook/

[ファブリス]

Looks like I should use Implicit grant type for mobile clients.

I still don't understand how the redirect url applies to a native app (say the Android app connecting trough http).

On Android and iOS you can register a protocol with the OS and have the app receive links from it. So if you plan to only use the app and no backend server, you can have the app tell the server the redirect url is something like "kanjiapp://mykanjiapp/auth" and the server will try to redirect there. This will trigger the registered protocol handler which points at your app and the app can then handle the rest.

All the redirect flows are for authenticating third parties. It's what all those SNS logins use. When you make a front-end app for your API (a trusted client), you can directly authenticate the user yourself, so you should be using the User Credentials Flow (grant_type=password). In this flow, you don't even provide the client_secret, because 1) you trust the client and 2) it's impossible to secure any sensitive data in an Android or JavaScript app anyway. You simply send the username/password and get back a JSON hash with the token data.

Strictly speaking, I'm not even sure if Oauth2 is necessary when you only have trusted clients, but rolling your own token-based authentication isn't trivial either, so it's probably best just to go with the standard. If that library is any good, then it shouldn't be too much work. I recommend installing the Chrome extension Postman to test your API.

[ファブリス]

@vix86 Ahh that makes sense, thanks!

@jimeux Thanks, I do not create the apps myself. So I like that OAuth lets Kanji Koohii users connect their account to a third party app without giving their password to the app. Also from what I understand the token will have a limited time so the user doesn't need to explicitly disconnect from the app if they stop using it or uninstall it.

My plan to keep things simpler first is that I will make some steps automatic. I won't create an interface for users to authorize/deauthorize individual apps. That seems over complicated, especially there may be very few Koohii apps. I will also at first ignore "scope" and basically give full access to the app. There's barely any personal information right now (email?) so I think that's fine. If I use OAuth then I guess if it becomes useful I can always use this "scope" feature to grant access to user's flashcards, while not giving access to their email, say.

Hmm in fact come to think of it the main API method to retrieve account info returns the email and I should probably remove that. Hmm.. maybe if the app uses the email to send notifications. I think I'll remove it now, easier to add later than remove it.

[ファブリス]

Ugh... seems like I'm really supposed to use SSL/TLS with OAuth2. Maybe I should use OAuth 1.

[ファブリス]

Sigh. And OAuth1 has a consumer_secret that can be found in the mobile app.

I could just consider the security "good enough", but what if the app is open source? Since porukkusu suggested the code would be publicly available, that means the consumer_secret isn't even obfuscated at all.

If someone forks the app and misuses the API (ie. stressing out the server), I need to know which is which. The consumer_secret can not be in the source code.

You can technically roll your own SSL Certificate. Only the API and Auth interface needs to done in HTTPS, although this might still throw warnings when people authorize. There are some free SSL certs out there you can use.

[ファブリス]

Hmm.. I have no experience with SSL at all. But I see now that I can use a shared SSL.

The shared SSL will issue a warning.

So when the client app sends the user to the authorize point within a webview, or separate browser, there will be some kind of alert box about the SSL? Can the user always skip that?

It's possible to remove the warning apparently if I give the server name instead of the registered domain name.

Eg. something like:

Code:

https://server1234.hostgator.com/~account/website/oauth2/authorize.php

... but I'll have to try because maybe OAuth2 will throw up again due to the domain name mismatch.

I haven't experimented with SSL enough to say what will happen if you use your own Cert. Generally Chrome/Firefox have a set list of cert providers that they accept signing for. An easy test for the whole thing would be to look into how to create your own cert, apply that on your server, and just create a dummy page and go there. See what Chrome/Firefox do.

But yes, users can usually skip warnings about certificate issues. The main ones that I know of are expired certs and certs that don't match the domain.