Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You've asked about the three methods of authentication; here's my current understanding:</p> <p><a href="https://dev.twitter.com/docs/auth/application-only-auth" rel="nofollow"><strong>Application-only</strong></a>: exactly what it says. Your application is assigned one set of access tokens (in addition to the consumer tokens which will be used regardless of auth type). Requests are considered coming from your app and not from a user.</p> <blockquote> <p>When issuing requests using application-only auth, there is no concept of a "current user." Therefore, endpoints such as POST statuses/update will not function with application-only auth.</p> </blockquote> <p><a href="https://dev.twitter.com/docs/auth/oauth/single-user-with-examples" rel="nofollow"><strong>Single-user</strong></a> This is when your entire app only has ONE user total. That's a pretty niche case, maybe something like a single user admin app. If you look at the examples, the tokens are all hard coded. What you are currently doing sounds similar except you are basically asking the user for the values and passing those in. As you noted, it's not ideal. In fact, the first thing on that page says Application-only will usually be more appropriate.</p> <p><a href="https://dev.twitter.com/docs/auth/implementing-sign-twitter" rel="nofollow"><strong>Sign in with Twitter</strong></a> There are a few steps in the process, but from the user's perspective they get redirected to twitter and agree to grant your application privileges on their behalf. You can then store the return tokens and issue requests.</p> <p><strong>I'm pretty sure SIWT is what you're looking for.</strong> Can it run on a schedule? I don't see why not... unless the tokens you get back expire after some time. It also may not be considered a best practice, but I can't find anything saying not to do it.</p> <p>I'm currently working on implementing this myself (for use as a quick and dirty log in method) and here is the code for the first stage of the process. The code is quite ugly but works.. you should get the initial oauth tokens back. I smashed my head against a wall for a few days while dealing with an incorrect server time (this can really mess you up) and shared your confusion on the @J7mbo wrapper.</p> <pre><code>$oauthStuffs = array( 'oauth_consumer_key' =&gt; "**YOUR_CONSUMER_KEY**", 'oauth_nonce' =&gt; base64_encode(openssl_random_pseudo_bytes(32)), 'oauth_signature_method' =&gt; 'HMAC-SHA1', 'oauth_timestamp' =&gt; time(), 'oauth_version' =&gt; '1.0', 'oauth_callback' =&gt; '**YOUR_CALLBACK_URL**' ); ksort($oauthStuffs); $method = 'POST'; $baseUrl = 'https://api.twitter.com/oauth/request_token'; $outputString = ''; $i = 0; foreach($oauthStuffs as $key =&gt; $value){ $outputString.= rawurlencode($key).'='.rawurlencode($value); $i++; if($i &lt; count($oauthStuffs)) $outputString .='&amp;'; } $baseString = $method.'&amp;'.rawurlencode($baseUrl).'&amp;'.rawurlencode($outputString); $consumerSecret = "**YOUR_CONSUMER_SECRET**"; $signingKey = rawurlencode($consumerSecret).'&amp;'; $signature = base64_encode(hash_hmac('sha1', $baseString , $signingKey, true)); $oauthStuffs['oauth_signature']=$signature; ksort($oauthStuffs); $headerString = "Authorization: OAuth "; $i = 0; foreach($oauthStuffs as $key =&gt; $value){ $headerString .= rawurlencode($key).'="'.rawurlencode($value).'"'; $i++; if($i &lt; count($oauthStuffs)) $headerString .= ", "; } $ch = curl_init(); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); curl_setopt($ch, CURLOPT_URL, $baseUrl); curl_setopt($ch, CURLOPT_HTTPHEADER, array($headerString)); $postFields = array( 'oauth_callback' =&gt; rawurlencode('**YOUR_CALLBACK_URL**') ); curl_setopt($ch, CURLOPT_POSTFIELDS, $postFields); $response = curl_exec($ch); echo $response; </code></pre> <p>If I finish this and I don't learn of another library that supports SIWT out of the box, I may throw it on github.</p> <p>If none of that works for you, maybe also look at this comparison of authentication methods: <a href="https://dev.twitter.com/docs/auth/obtaining-access-tokens" rel="nofollow">https://dev.twitter.com/docs/auth/obtaining-access-tokens</a></p> <p>[update: I implemented the whole thing myself and got it to work, but I'd instead suggest looking at some other libraries such as <a href="https://github.com/abraham/twitteroauth" rel="nofollow">abraham/twitteroauth</a>]</p>
    singulars
    1. This table or related slice is empty.
    1. POUsing the Twitter API with an app - using app OAUTH keys or user logging in
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USJere
    1. USJere
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POUsing the Twitter API with an app - using app OAUTH keys or user logging in
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COWow, thanks for this. This certainly clarifies things. Twitter could do with making their docs easier to understand. It would also be great if we could make the PHP Wrapper from j7mbo have SIWT. I've not tried your solution yet, but I'll have a go later. I've never got my head round how call back urls work. In your script are the user's oauth tokens posted to the call back url? Could I then use these in j7mbo's script or have I completely misunderstood this?
      singulars
      1. PO
      1. USiagdotme
    2. CODuring SIWT, you will send the user to twitter's website so they can see that the whole thing is legitimate and can grant your app access. After that happens, twitter has to send the user back to *your* website. The callback URL specifies where they'll go. Regarding the tokens, j7mbo's wrapper assumes you have already have 4 token/secrets (consumer, consumer secret, access, access secret). You're using SIWT to *get* the latter two (the user's own access token). With the code I posted, you'll start out not knowing that. After you get them, I think the wrapper could be used as expected.
      singulars
      1. PO
      1. USJere
    3. COOK, I am starting to understand this. I've tested your script (I had to used an alternative to `openssl_random_pseudo_bytes` as it's not available to me. Your script returns an oauth_token and an oauth_token_secret. I assume this is randomly generated for the app by Twitter and this can be passed on to the wrapper script. What I don't understand is how I send the user to Twitter in order to grant access to my app? Also, when that happens, I assume the oauth tokens I get back will be for that user? And the wrapper script will have access to that users' Twitter account until revoked?
      singulars
      1. PO
      1. USiagdotme
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload