My app uses LinkedIn authentication along with a couple of other social network logins.
Even though authentication is working fine, all of a sudden LinkedIn stopped returning the formatted profile picture i.e. picture-url. I do however continue to receive the original image i.e. picture-urls -- see below:
In my authentication request, I request r_basicprofile and r_emailaddress and according to this link, I should be receiving both the formatted and the original image.
https://developer.linkedin.com/docs/fields/basic-profile
Up until 10 days ago or so, I was receiving both images. I didn't make any changes to my code but for some reason, the formatted image doesn't show up anymore. Any idea why and how to fix this?
UPDATE:
All of a sudden I started getting both images again -- without making any changes to my code.
I also noticed that the image URL has now changed and I'm seeing all types of parameters in there -- such as image size, something that looks like API version type (alpha in the example below) and possibly a time stamp indicator:
https://media.licdn.com/dms/image/{image-id}/profile-displayphoto-shrink_100_100/0?e=123456789&v=alpha&t={sometypeofid}
I don't remeber seeing any of these parameters in the image URL which is not a URL at all but what seems to be an API call that returns an image.
I don't know if LinkedIn announced such changes that I missed or just decided to make these changes without keeping developers in the loop. I hope it's not the latter and I simply missed the announcement.
Related
I was creating an API for TD Ameritrade (my first time creating or dealing with APIs) and I needed to put in my own call back URL. I know that callback URL is where the API sends information to and i heard that I can just use my localhost API. I scoured the internet and I dont know how that would work and I was wondering if i can just use http://localhost?
Sorry if I seem like a noob because I am
In short, yes.
Follow the excellent directions at
https://www.reddit.com/r/algotrading/comments/c81vzq/td_ameritrade_api_access_2019_guide/. (Even with them, I spent excessive time on trial and error!)
Since stackoverflow has a limit of 8 links in a response, and the localhost text string looks like a link, I’m showing it with the colon replaced by a semicolon, i.e., http;//localhost to reduce the link count. Sorry.
I used the Chrome browser after first trying Brave, which did not work for, possibly because of my option selections.
Go to https://developer.tdameritrade.com/user/me/apps
Add a new app using http;//localhost (delete existing app if there is one).
Copy the resulting consumer key text string (AKA client_id or OAuth User ID).
Go to https://developer.tdameritrade.com/content/simple-auth-local-apps, follow instructions. Note: leading/trailing blanks were inserted by MSWord due to copy/paste of the auth code, which had to be manually deleted after wasting excessive time identifying the problem. The address string looks like:
https://auth.tdameritrade.com/auth?response_type=code&redirect_uri=http%3A%2F%2Flocalhost&client_id=ConsumerKeyTextString%40AMER.OAUTHAP
This returns a page stating the server refused to connect, but the address bar now contains a VeryLongStringOfCharacters in the address bar:
https;//localhost/?code= VeryLongStringOfCharacters
Copy the contents of the address bar, go to https://www.urldecoder.org/, decode the above, and extract the text after “code=”. This is your refresh_token
Go to: https://developer.tdameritrade.com/authentication/apis/post/token-0, fill out the fields with
grant_type=authorization_code
refresh_token=<<blank>>
access_type=offline
code=RefreshTokenTextString
client_id=ConsumerKeyTextString#AMER.OAUTHAP
redirect_uri=http://localhost
Press SEND.
If the resulting page starts with HTTP/1.1 200 OK, you have succeeded.
Try updating your redirect to:
redirect_uri=https://localhost
They may require https now and you need a colon instead of a semicolon. Everything looks correct. This process generally takes me more then one attempt, and 15 minutes to an hour to get my refresh token squared away every 90 days.
dont use #AMER.OAUTHAP in client_id
If you generate a new code and based on that try to get a new access token. it should work.
I use social authentication in my ASP.NET Core application, one of which is LinkedIn authentication.
Looks like there's been some changes in LinkedIn API and now we seem to get some parameters with user images.
Here's a dummy full/original image URL I'd get from LinkedIn API. Any idea what these parameters mean? In particular, the one that begins with t?
https://media.licdn.com/dms/image/A1205CPGrwDzHZS_Apr/profile-originalphoto-shrink_900_1200/0?e=1525989600&v=beta&t=PNuO2bh5rNrIJv19PN1OXOjzDWcQgKdYCl1-ZVzgPOw
The reason why this is important is that when the user logs in, I compare the data that's already in the database with the new data coming from LinkedIn -- in my case, it's limited to user profile images i.e. both the smaller size image and the original one the user uploaded.
I've noticed that the image is always showing different. In closer analysis, I could see that these parameters, in particular the one that begins with t is where the difference is. This small change triggers an event in my code to update the user's images which could be a completely wasted database call. I could confirm this with my own LinkedIn login. Even though my image hasn't changed, the image URL for the original image is always different due to this difference in the t component.
The t parameter could be some type of time stamp which means it may always be different. I don't want to make that assumption, hence this questions.
I tried the below LinkedIn endpoint 'https://api.linkedin.com/v2/me?oauth2_access_token='.
For me, there are two images under "pictureInfo" section, "croppedImage" and "masterImage". I have tried to replicate the problem you have mentioned and could not replicate this for sometime. At some point, I have received a different image URN for "masterImage". After a no. of tests I understood the 'masterImage' is updating once in every hour. With this I have further tried to understand the parameters in the image URN.
From these,
v=beta is clear. Earlier it was v=alpha for few.
e appears to be a timestamp which relates to some expiration.
t is changing when e changes.
Given this analysis if you are using 'masterImage' to trigger a DB call, you may put regex matching criteria to identify actual change in image.
Using the Contact API v3 I had a working implementation for uploading a photo to an existing contact.
Since a couple of weeks this fails with 404. The implementation has not been changed when the API servers started to sent back 404s and I don't see any indication what exactly changed and would result now in the 404s.
I'm using HTTP PUT + the photo URL of the contact.
One interesting observation I made was that the contact's self-URL changes which each request (the provided details are still always the same and correct).
Did anyone notice something similar ?
Edit: Link to issue: http://code.google.com/a/google.com/p/apps-api-issues/issues/detail?id=3301&q=contact&colspec=API%20ID%20Type%20Status%20Priority%20Stars%20Opened%20Summary
tried different photo formats and sizes, different content types and even photos which had been uploaded previously (when it was still working). Nothing changed the behaviour of returning 404.
w.r.t to change contact ids: the contact ID changes between API invocations. I first thought it could be related to reopened connection( no keep-alive) that contact ids change. However what speaks against this being the cause of the issue is that first retrieving a contact and then editing a contact's address is possible without any issues.
authentication does not seem to be problem as well - otherwise editing a contact's address would not work as well.
PS: I'm using the JSON output format when retrieving the contact.
PS2: s/GET/PUT in step 3 ( I tried to change PUT to GET to see if it still returns 404... which it does).
PS3: am not using any client library but implement the protocol directly (which should not be relevant for the HTTP PUT on the photo link
After hours of investigation I found out that this is particular an issue using OAuth1. Using OAuth2 the exact same photo links which had been returned when requesting a specific contact record using OAuth1 work and return the photo data on HTTP GET. I expect HTTP PUT for photo links using OAuth2 to succeed as well.
Remains open if if there's some kind of workaround for OAuth1.
We have a few sites that run on different CMS (Drupal, Joomla etc.). We would like these sites to share a phpbb forum (on a different domain) and for people that register on each site to have a user account automatically created on the forum as well.
For that I have writen a script that sends a php curl request that mimics phpbb's registration process.
First, I tired a simple sign up form and it worked well. But since the forum uses Captcha I needed to add a form to my script so the user could input the Captcha string. And here things did not pan out so well. After many hours of examining the phpbb code files I managed to more or less put my finger on where the problem occurs, although my limited phhbb knowledge prevents me from finding a solution so I thought I would ask for help here.
My script sends a curl request to ucp.php?mode=register to get past the "agree to terms" screen, parses the result to get the tokens and creation time and then sends another request. The returned value is the registration screen with the Captcha image. Except no image can be seen as the url to the image script is relative and so I alter the output result and make the url an absolute url.
So instead of
./ucp.php?mode=confirm&confirm_id=xxxxxxxxxxxxx&type=1
I alter the code to
http://www.mydomain.com/phpbb3/ucp.php?mode=confirm&confirm_id=xxxxxxxxxxxxx&type=1
And get a Captcha image (xxxxxxxxxxxxx is the confirm_id string that changes every time).
And this is where I hit a brick wall. The image generated is never the correct captcha string.
If I var_dump the $captcha variable in ucp_register.php I can see the correct string which is never the one in the Captcha image. I placed bits of code in the phpbb files that output certain variables to help me understand what's going on behind the scenes. Here is what I managed to gather, hoping some one could tell me why it's happening or at least point me in the right direction:
In captcha_abstract.php and captcha_gd.php the is the variable $this->confirm_code. When I dump this into a file in both cases I can see the right captcha code (same as when I output the $captcha var in ucp_register.php).
In ucp_confirm.php there is the $captcha->code var which turns out holds the string that I see when I output the Captcha image.
When I just go through the registration process normally through the browser $this->confirm_code and $captcha->code holds the same value.
So it's obvious that changing the ucp.php?mode=confirm line above is causing this, yet I can not avoid that as if I don't do it I don't get a Captcha Image.
Graph API is not returning image("picture" attribute) for objects corresponding to community pages, which used to be returned earlier. For example this https://graph.facebook.com/178790412179919 does not have picture attribute whereas the corresponding page has an image.
Also the FQL query done on the "albums" connection for some objects does not have a "cover_pid" attribute for an album corresponding to type "profile", which again used to work earlier.
Does anybody know if anything has changed in Graph API corresponding to this in last couple of weeks (I am fairly confident it used to work earlier in the expected way). I looked through Facebook API release notes but could not find any changes corresponding to this. Please let me know if this not appropriate post for this forum.
https://developers.facebook.com/docs/reference/api/page/
picture is a connection, not an attribute. So ...
https://graph.facebook.com/178790412179919/picture
And as the docs say: Returns a HTTP 302 with the URL of the user's profile picture.
Kinda goofy? Yes, but it works exactly as the docs say it does. I suspect they implemented it this way so it could easily be used in an <IMG> tag.
UPDATE:
It still works via FQL. In your case:
https://api.facebook.com/method/fql.query?query=SELECT+page_id%2C+pic+FROM+page+WHERE+page_id+%3D+178790412179919&format=json
I can confirm that this PREVIOUSLY worked, but NO LONGER works. Facebook have removed the picture connection from Community Pages.
I suspect the reason is that most of these images are pulled from Wikipedia, and there was a licensing / attribution issue.
Unfortunately, Facebook is no longer a reliable source of images for entities (e.g. bands).