The most common use cases should be documented in the wiki

[gonzalo-bulnes]

As a developer In order to avoid mistakes when using Simple Token Authentication I want the documentation to the most common use cases

As an documentation contributor
In order to make sure the documentation stays up-to-date And to make it easy to edit, extend and amend I want it to be under version control And to be open for contributions

Idea: use the wiki engine provided by Github.

[gonzalo-bulnes]

Which are the most common use cases? I would say:

• Add token authentication to an API built from Rails
• Add token authentication to an API built from Rails::API, see #94
• Use token authentication within a Rails app (sign in from an e-mail for example)
• Add token authentication to an API built from Rails::API and Mongoid, see #38 and #97

See also: #93

What do you think?

[ianks]

Seems about right. What about including basic info about different client frameworks a la Angular or Ember?

[gonzalo-bulnes]

I personnaly would appreciate such a doc, let's see if we succeed in gathering it @ianks.

[ianks]

OK, I will keep this in mind as I setup my Angular app.

[gonzalo-bulnes]

Also:

• Generate signin links to allow automatic signin from an e-mail for example, see #163

[johnmosesman]

Maybe this should be referenced here? #179

[gonzalo-bulnes]

This issue was meant to reference use cases, but anyway the mention to #179 doesn't hurt : )

[ssurfr2819]

I just found your gem and related resources (very promising!), and I'm trying to learn if our use cases can be supported out of the box, and or with some adaptations to the app, the mobile client code, Devise, or the gem... I would think that our use cases are common in today's market. Perhaps they are ready to go "out of the box" with your gem, but if so, I can't tell for certain because the various comments and responses are time-sequenced rather than grouped by use cases. (This isn't a criticism of everyone's work. It's just reality when reviewing for the first time.)

So anyway, I hope to receive your response to these use cases - that is, are they described in a single document already, and or do you have pointers?

• The Rails application can be accessed via browser with standard devise session based auth. AND
• Mobile phone client apps can access via json api - either via token and or session (stored) depending on best practice. AND
• Mobile phone client apps also occasionally use "WebView" controls to launch an in-app HTML page (GET) served by the Rails app. (Perhaps using the api path so that controller can recognize need for different layout template.) AND?
• Other business systems will also use the json api, but that's probably satisfied by the above, possibly with addition of api key to prevent access across systems.

Achieving the above with a single easy to maintain code base would be much better than some of the gyrations we go through in our current implementations.

I've seen some of the above use cases partially described in your issues. I also believe I read in one comment that 'if you use the Simple Token Authentication methods, then you can't also use Devise standard techniques'. But that information might have just been an early situation, that was later overcome by enhancement (e.g. release 1.7 Rails API support).

Please don't hesitate to let me know if I'm over complicating things.

[gonzalo-bulnes]

Hi @ssurfr2819,

Ooops, I somehow missed your message, I'm sorry for that... it has been a long time. For the record, all but the last bullet point are common and supported use cases. And the idea of Simple Token Authentication is being able to support token authentication along with all the other Devise authentication methods ("standard techniques") - this has always been the idea, and is independent of the Rails API support. (Supporting Rails API means that you can make any controller that inherits from ActionController::API act as a token authentication handler in the same way as standard Rails controllers - which inherit from ActionController::Base.)

Anyway, I am currently reviewing the docs structure (see #271) because I understand the case-by-case approach would be better for quite a few people. And I'll be updating the use cases I know of.