Opensea Websites has a feature to Direct Buy a Token on Make an offer.
Is it possible to find whether a token is buyable or not through opensea API?
I couldn't find a solution so far.
Related
Our application can show rich links to webpages. So instead of a mere weblink we show a short summary and a picture. We used to use embed.ly's extract api to supply us with this data, but since they have changed their terms and pricing we have implemented an alternative solution.
The problem we find is that linkedin profile urls cannot be assessed by our new solution. Embedly was able to give us all the details we needed from a linkedin profile url (including the user's picture), but we don't seem to have access to that information without going through linkedin's API.
This call gives us all the data we are looking for:
GET https://api.linkedin.com/v1/people/url=[PROFILE_URL]:(id,email-address,first-name,last-name,headline,summary,formatted-name,picture-url,picture-urls::(original),site-standard-profile-request,public-profile-url)?format=json&oauth2_access_token=[TOKEN]
Where [PROFILE_URL] is a linked in profile url and [TOKEN] is the oauth2 access token.
There are two issues that I have:
Our application does not ask users to authenticate through linkedin, so we do not have a user oauth2 access token available;
Linkedin's suggestion in their FAQ (https://developer.linkedin.com/support/faq) seems very daft:
Can I get an access token for my application that doesn't require a member to login?
We do not provide access tokens for applications that are not associated with a particular LinkedIn member.
If your application requires you to make API calls in an automated way - without user interaction, you need to bootstrap the first access token request by manually signing in, and then ensure that your application refreshes the token automatically prior to expiry to avoid the need for additional human authentication.
Now... four questions:
a. Has anyone implemented option [2] in a production setting?
b. If yes, what are the limitations, downsides etc. Is this really the best and safest solution?
c. Is there any alternative that allows me to authenticate the application itself with its mighty client key and client secret?
d. Is there anyone from linkedin monitoring this? If yes, can you contact me?
Cheers, Raymond
After 2 weeks of searching with no luck, I ended up writing this question:
Can you help me how to authenticate into Office365 on iOS? My goal is to list all rooms in my company included in outlook.
Is connecting to Sharepoint a solution for this? If it is so, how should it be performed and to which link shall be send credentials?
Is basic authentication enough to access those services?
I have tried doing authentication to EWS, but at the end of the day it turn out wrong.
Thank you for your answers.
Your best bet is going to be the OWA app for iOS. If you are looking to access all of the room mailboxes from a single location. You can manage multiple accounts from the OWA app if that is what you are after. Aside from the the Office Mobile app has the other collaboration pieces that come along with certain licenses in Office 365.
This is a very high level question, to a high level answer too, so I'm just looking for some pointers on the right direction.
Let's say I want to build a web application to manage a user's Google Contacts. I understand this is done by allowing the user to log in with his Google Account while asking for permissions to manage his Google Contacts. So far so good.
Now I want to expose my own API layer for external browser extensions, Android clients, etc. But while I want the API clients to authenticate against Google, I don't want the applications to have full access to the user's Calendar, as the Secret Token is stored on the server.
So, how is this typically handled? I would like to do it by the book as much as possible, without having to implement a lot of security code.
Btw, while the question is too high level, feel free to point me to technical docs.
Thanks
Limited access to the user's resources can only be guaranteed by limited OAuth scopes:
https://developers.google.com/gdata/docs/auth/oauth#Scope
Some APIs, for instance the Contacts API, only provide a single scope which gives you access to all the data. In cases like this, the user can only choose between giving you access to all his contacts or none of them.
Other APIs expose different OAuth scopes, allowing the developers to only request access to a subset of the user's data. A good example of this is the Google Drive API, which has 5 different scopes for the developer to choose from:
https://developers.google.com/drive/scopes
Let's say I am making a sign up form in which I asked user's twitter ID. How do I verify if the ID entered by user belongs to him/her? In case of verifying email we simply send a verification link which user has to click so how do I verify twitter ID? I have never used twitter before.
The only reliable and practical way to verify that twitter account X belongs to user Y this to do full on “3 legged” OAuth authentication. That being said, you may want to consider if you might be OK with just taking the user at their word on it.
Getting OAuth to work and securely storing the resulting tokens is much easier nowadays than it once was, but is still non-trivial.
Reasons to verify the twitter account, in increasing reasonableness:
You will be making enough server side requests, on behalf of multiple users, that you run up against Twitter’s API Rate Limiting. (Having multiple auth-tokens will allow for a higher API rate)
You need to automagically send tweets and/or follow accounts on the user’s behalf
N.B. do this as opt-in and be ultra clear about when/why you will be doing this, or you will face the justified fury of scorned users
Don’t verify the account if you’re looking to do these things:
You need to send tweets and/or follow accounts on the user’s behalf, and the user will be able to perform a browser based confirmation workflow for each of those actions; use Twitter’s Web Intents for this.
If you just want to pull in real time data for user’s avatar, bio, or recent Tweets Twitter supplies some prefab widgets for you.
All of the authenticated Twitter API Calls can be done client side with JavaScript. Twitter has a js framework, which does not require you to handle and store tokens on your server, to help you with that.
An alternate contact method for password resets, notifications, etc.
Private communication between users on twitter requires mutual following, many users probably never check their Direct Messages (or even know what a DM is), and any messages would be limited to 140 characters. Just use email for all that kind of nonsense.
If you’re just gathering this info to display it on a user’s profile page, in an “other places on the web” kind of way, integrating and maintaining all the server side OAuth pieces is likely too much bother. Just make sure you have a reasonable and clear TOS and an obvious way for 3rd parties to report any of your users who may be claiming a twitter account that is not their own.
If you’re still interested in OAuth, Twitter's Dev page has plenty of resources, including a nice overview of a generic “Sign In with Twitter” “3 legged” OAuth work flow.
Could anyone please summarize the differences between Twitter's REST API and its Streaming API?
And does either of them uses Push technology?
The REST API lets you query or modify a user's account. You don't need their permission to query their account, you do need it to modify their account. They provide permission through OAuth authentication.
The streaming API delivers tweets based on search terms or for specific users you request, along with info about the author, in real-time. You do not need the tweet author's permission. You must log into some Twitter account to use streaming, using either basic or OAuth authentication.
Neither uses push, but streaming is a continuous net connection, so it is real-time delivery, making it functionally similar to push.
For anybody coming to this more recently, The REST API (v1.0) has now been retired with v1.1 being the only version. This Does now require authentication for everything, including reads.
Authentication required on all endpoints
In version 1.1, we're requiring applications to authenticate all of
their requests with OAuth 1.0a or Application-only authentication. Not
only will this visibility allow us to prevent abusive behavior, but it
will also help us to further understand how categories of applications
are using the API. We'll apply that understanding to better meet the
needs of developers as we continue to evolve the platform. At this
time, all authentication requires user context, but in the coming
weeks we'll be pushing out support for a form of authentication not
requiring a user context.
Actually you can use search through the REST API as well. For example it's the only way to combine geo AND query keyword, while the Stream API can only use OR logic.
I think it's about defacto push streaming as Adam Green has said.