L'invio di oggetti a Facebook tramite un grafico aperto non funziona, ma funziona dopo aver testato l'URL nel debugger di oggetti di Facebook?

Question

Desidero consentire a un utente della mia app Web di essere in grado di pubblicare più oggetti sulla timeline da una pagina (pagina principale).

Ho già memorizzato il token di accesso dell'utente.

Tag a pagina Sto cercando di inviare, l'url è PAGE_URL:

codice

<meta property="fb:app_id"  content="my_app_id" /> 
<meta property="og:type"  content="my_namespace:my_object" /> 
<meta property="og:title"  content="some string" /> 
<meta property="og:description" content="some other string" /> 
<meta property="og:image"  content="some_image_url" /> 
<meta property="og:locale"  content="en_US" /> 
<meta property="og:url"   content="page_url" /> 

Rails a presentare l'url, innescato da main_page:

begin 
    fb_post = RestClient.post 'https://graph.facebook.com/me/my_namespace:do', :access_token=>user.get_facebook_auth_token, :my_object=>"page_url" 
rescue StandardError => e 
    p 'e.response is' 
    p e.response 
end 

uscita

2011-11-02T02:42:14+00:00 app[web.1]: "e.response is" 
2011-11-02T02:42:14+00:00 app[web.1]: "{\"error\":{\"message\":\"(#3502) Object at URL page_url has og:type of 'website'. The property 'my_object' requires an object of og:type 'my_namespace:my_object'.\",\"type\":\"OAuthException\"}}" 

La cosa veramente strana è che, dopo aver ottenuto questo Per esempio, se provo il page_url su Object Debugger, passa senza errori/avvisi, il og:type è il tipo corretto e la nota 'website' e quindi che esegue lo stesso codice Rails di cui sopra funzionerà bene.

Ho provato senza il tag og:url e succede la stessa cosa.

UPDATE:

Come per la risposta di Igy, ho provato separa il processo oggetto raschiando dal processo di azione creazione. Quindi, prima che l'azione fosse inviata per un oggetto nuovo di zecca, ho eseguito uno update su un oggetto, con scrape=true.

begin 
    p 'doing fb_update' 
    fb_update = RestClient.post 'https://graph.facebook.com', :id=>page_url, :scrape => true 
    p 'fb_update is' 
    p fb_update 
rescue StandardError => e 
    p 'e.response is' 
    p e.response 
end 

uscita

2011-11-05T13:27:40+00:00 app[web.1]: "doing fb_update" 
2011-11-05T13:27:50+00:00 app[web.1]: "fb_update is" 
2011-11-05T13:27:50+00:00 app[web.1]: "{\"url\":\page_url,\"type\":\"website\",\"title\":\page_url,\"updated_time\":\"2011-11-05T13:27:50+0000\",\"id\":\id_here}" 

La cosa strana è che il tipo è website, e il titolo è l'URL della pagina. Ancora una volta, ho controllato sia l'HTML che il debugger di Facebook, e il tipo e il titolo sono entrambi corretti in quelli.

Answer 1

sto correndo lo stesso problema.

L'unico modo sono stato in grado di pubblicare con successo le azioni per i tipi di oggetto personalizzato che ho definito è quello di testare manualmente l'URL oggetto con Object Debugger prima, e poi inviare l'azione su tale oggetto attraverso la mia domanda.

Anche utilizzando l'API linter - che Facebook suggerisce here - mi dà un errore.

curl -X POST \ 
    -F "id=my_custom_object_url" \ 
    -F "scrape=true" \ 
    "https://graph.facebook.com" 

Solo lo strumento debugger sembra raschiare la pagina correttamente.

Si noti che non ho avuto questo problema quando si utilizza un tipo di oggetto predefinito, come "sito web":

<meta property="og:type" content="website" /> 

Questo problema sembra soltanto interessare tipi di oggetti personalizzati per qualche motivo.

UPDATE (con la soluzione):

fine ho capito questo. Il problema in realtà è nato dall'incapacità della mia applicazione di gestire due richieste HTTP simultanee. (FYI: Sto usando Heroku per distribuire la mia applicazione Rails.) Quando si effettua una richiesta all'API di Facebook per pubblicare un'azione su un URL oggetto (richiesta n. 1), Facebook tenterà immediatamente di raschiare l'URL dell'oggetto specificato (richiesta # 2), e in base a ciò che è in grado di racimolare con successo, restituisce una risposta alla richiesta originale. Se eseguo la richiesta n. 1 in modo sincrono, legherò il mio processo web su Heroku, rendendo impossibile per la mia applicazione gestire la richiesta n. 2 allo stesso tempo. In altre parole, Facebook non può accedere correttamente all'URL dell'oggetto che deve analizzare; al contrario, restituisce alcuni valori predefiniti, incluso il tipo di oggetto "sito web". È interessante notare che questo si è verificato anche quando ho attivato più processi Web su Heroku. L'applicazione intendeva utilizzare lo stesso processo web per gestire entrambe le richieste.

Ho risolto il problema gestendo tutte le richieste dell'API di Facebook come lavori in background (utilizzando delayed_job). Su Heroku, ciò richiede l'attivazione di almeno un processo Web e un processo di lavoro. Se riesci a farlo, eseguire le richieste API in background è comunque una buona idea poiché non lega il tuo sito web agli utenti, facendoli aspettare diversi secondi prima che possano fare qualsiasi cosa.

A proposito, consiglio di eseguire due processi in background. Il primo dovrebbe semplicemente raschiare l'URL oggetto postando: https://graph.facebook.com?id= {object_url} & raschiare = true

Una volta che il primo lavoro è stato completato con successo, il fuoco su un altro lavoro sfondo POST un'azione alla timeline: https://graph.facebook.com/me/ { app_namespace}:? {} action_name access_token = {} user_access_token

più recenti UPDATE:

per il suggerimento nei commenti, utilizzando Unicorn sarà anche fare il trucco, senza la necessità di delayed_job. Vedere più qui se si sta utilizzando Heroku:
http://blog.railsonfire.com/2012/05/06/Unicorn-on-Heroku.html

Answer 2

The Object creation documents dicono che dovrebbe raschiare un oggetto la prima volta che si crea un'azione contro di essa, ma anche dire

In alcune piattaforme di hosting e di sviluppo in cui si crea un oggetto e pubblicare su Facebook contemporaneamente, è possibile ottenere un errore dicendo che l'oggetto non esiste. Ciò è dovuto a una condizione di competizione esistente in alcuni sistemi.

Si consiglia di (a) verificare che l'oggetto sia replicato prima di pubblicare un'azione o (b) introdurre un piccolo ritardo per tenere conto del ritardo di replica (ad es. 15-30 secondi).

Sulla base di questo, penso che è necessario aggiungere &scrape=true alla chiamata iniziale per forzare un raschiare immediato, quindi provare a creare l'azione un po 'più tardi. (Credo che il messaggio di errore che stai ricevendo è probabilmente perché la pagina non è stata memorizzata nella cache/raschiato ancora.)

Answer 3

Da quello che ho visto, il Facebook Debugger Page è il migliore (e, per la maggior parte degli scopi pratici, solo) modo per forzare le cache di Facebook di una determinata pagina di Informazioni OpenGraph da aggiornare.Altrimenti, spenderai fino a una settimana in attesa delle informazioni memorizzate nella cache relative alle pagine che hanno già raschiato.

In sostanza, si dovrebbe

1. Riscrivere le pagine di agire come volete
2. Far passare gli URL pertinente alla pagina Debugger (per vedere che convalidano, e per aggiornare le cache), e then
3. Consenti alle pagine di essere pubblicate "normalmente" per vedere le tue modifiche in azione.

Ci possono essere altri modi per forzare la scadenza delle cache di Facebook; vedi this Stackoverflow page per alcune possibili soluzioni. Non li ho ancora provati, ma potrebbero essere utili.