LinkedIn Share Post URL with parameter - linkedin

I have created a post on my websites when I shared on LinkedIn, it's not showing complete URL of sharing.
Currently, I am using https://www.linkedin.com/sharing/share-offsite/?url=www.example.com/share/?id=12654
But When I am sharing with LinkedIn using above its redirect to below URL :
www.example.com/share
Its removing parameter which passed using id. How I can get the full URL: www.example.com/share/?id=12654

Don't forget to do URL-encoding with parameters you are feeding to another URL. So, your link should be ...&url=https%3A%2F%2Fw..., and not ...&url=https://. Your URL also contains a question mark that should be escaped. Ultimately, your URL should look like this..
https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.example.com/share/%3Fid=12654
URL encoding is required any time you are sending a URL as an argument to the GET param of another URL.
In case you want to know more: Official LinkedIn Share Documentation
If you are interested in a regularly maintained GitHub project that keeps track of this so you don't have to, check it out! Social Share URLs

Related

Can you get the url of the shared content on Linkedin API?

I am implementing some code that posts content to the user Linkedin , the request response will have the shared object ID like "6777623868333944834".
What is weird the response does not contain a url to this shared/public object. If I check the urls of this posts from the website I see urls like
https://www.linkedin.com/posts/activity-6777623868333944834-PUJ7
https://www.linkedin.com/posts/activity-6777985031844458497-h4BO
https://www.linkedin.com/posts/activity-6777947888103243776-Yy4A
so Linkedin used the ID in the url but adds this extra 4 characters at the end.
I am wondering if I can somehow get the correct url without a new request.
I am not using any special library or SDK, just doing the requests directly,
If is not possible I am not able to find the correct API and permissions I would need to get the url if I have the ID (or urn)

when sharing a redirect url (response code 302) on linkedin, shared content has the redirected url (response code- 200)

From my app I want to share contents on linkedin with a redirect url this is because when request comes from linkedinbot I want it to redirect to a different page from where it can gets all the meta tags, but if it comes from browser I want to show a different page(an iframe) for users.
For example:-
I want to share the below link "https://example.com/something/1000/redirect" after sharing the above link on linkedin the content have the following href "https://example.com/something/1000/social" which I don't want instead I want the same redirect url as href on the content.
Everything is working fine for facebook and twitter
Typically, you do not want to do any type of redirecting for search engines, or they may mistinterpret your redirection as abuse. Take a look at the Google Ads Policy...
The following is not allowed:
Not allowed Engaging in practices that attempt to circumvent or interfere with Google's advertising systems and processes
Example 1: Cloaking (showing different content to certain users, including Google, than to other users)...
So, you may have metadata stored in og: tags, oEmbed pages, rdf format, dc: dublin core tags, or actually plain simple metadata HTML tags.
Why would you want to show one set of this information to the user and another set to the search engine? What harm does it do to have the user see what the search engine sees, and vice versa?

unwanted URL appended to redirection url

We have a asp.net web application will send a confirmation email with redirection url to users email once they confirm the registration. But while sending the url, the url "https://exchcas/owa/redir.aspx?C=cUl43mOPekKnIMaLWRr1yZSp78A6N9EIC9oVlRLrzMFpuM-1UucMKAHOqY5VYM297Nr6m36XwhM.&URL=" will be appended to our url.
for example,
our redirection url is http://localhost:63554/Reg.aspx
the url will be send some thing like below,
https://exchcas/owa/redir.aspx?C=cUl43mOPekKnIMaLWRr1yZSp78A6N9EIC9oVlRLrzMFpuM-1UucMKAHOqY5VYM297Nr6m36XwhM.&URL=http://localhost:63554/Reg.aspx.
Can anyone pls let me know why this append happening? and what is the meaning of this appened url?
This is a standard Exchange behavior for security reasons. Available in Exchange 2003/2010 (not sure about 2013). In OWA email is located at .../username/inbox/message.eml. If user clicks on direct url such as http://localhost:63554/Reg.aspx then on that link you could read HTTP_REFERER value and obtain "/username/inbox/message.eml". So, the purpose of having redir.aspx is to avoid sharing a username and email subject as a part of HTTP_REFERER.
Read more here http://blogs.technet.com/b/exchange/archive/2004/07/26/197289.aspx
You can also take a look here http://blog.leederbyshire.com/2013/03/28/how-to-make-your-outlook-web-app-2010-redir-aspx-a-little-safer/
I wrote a skip-owa-redir userscript that replaces each indirect redir.aspx link with a direct link to the target URL, using rel="noreferrer" to address the privacy concern.

Searching for existing research on http redirects and browser history

For a web app I want to let users review and edit a record they made previously through a browser form. In their confirmation mail, they get an access link with a secret token, like http://myapp.com/edityourstuff/hdD8sF2m Clicking this link shows them a form in which they can edit the existing data they submitted earlier.
This is not as secure as a username/password combination, but much more convenient and suitable for my situation.
However, I want to make this as secure as possible.
GET URLs
If the link containing the secret access token is disclosed, unauthorised people can access the data. My concern here is about shared/public computers.
I was planning to tackle this problem with the following pattern:
Access to /edityourstuff/ds8sdfhe via link in email
Start a session, store the secret token in there
redirect to clean /edityourstuff without token
The app now has access to the token in the session and can display the form accordingly. And the URL bar does not show it.
My question now is: Do browsers store the initial URL, that immediately redirects to the clean URL in their history?
I know that the different HTTP redirect status codes (301, 302, 303) have different use cases in theory. Is there any information on how different browsers treat the different redirect codes in respect to (not) storing the initial URL in browser history?
I just did some quick testing myself, with Firefox 7.0.1
When using the above pattern, no matter if 301, 302 or 303 redirect, Firefox does not return to the initial URL when clicking the back button. However, it is shown in the full browsing history and is part of the URL completion list of the browser bar.
This is exactly the drawback I was hoping to avoid.

suggestion for placing tracking cookie just like google adword

I have a contact us form in our website which would send out an email to the site admin when submitted. I would like to know from which site the user has landed onto this page and how many unique users have come here and such things... I have used Google Analytics but it sends out only information on the adword that the user has clicked. I would like to know from which site and from the user came in so that I can add this referring site when email is being sent to the site admin.
I am guessing that the referring site will always have some URL manipulation to redirect here so how can i grab that URL? or is there any other better way to achieve this?
Does the environment variable HTTP_REFERRER give what you want?
You can can begin collecting this data without adding any javascript to your Site's pages, using your server's access logs. If your server is Apache, then as long as you set your config file to record data to your access log in the Combined Log Format, then you are already collecting referrer (i.e., this is one of two additional fields appended to each line in the logfile when you specify the Combined Log Format versus the (default) Common Log Format, the other field is the user agent; both 'referer' and user-agent are taken from the respective HTTP request headers).
Another advantage of this method is that if you have been logging using the Combined Log Format, then you also have the data you want going back in time, as far back as you archive your logfiles.

Resources