I am confused about this upcoming Twitter API 1.1 change and how to re-implement functionality like that that used to be provided by jquery widgets like http://tweet.seaofclouds.com/ and http://thomasbillenstein.com/jTweetsAnywhere/.
I have been able to get linq-to-twitter to do a search using the ApplicationOnlyAuthorizer to at least get most of the information into a GridView, but this will re-use the same tokens (the ones belonging to the application) over and over, and will very quickly burn through 450 requests in 15 minutes when deployed to a live site with hundreds/thousands of active users...
In addition, for display I'd rather be able to re-use one of the basic jquery plugins out there, so it seems I'd have to point the jquery ajax call to a local page method or web service to make the server-side call for me...then if I were using linq-to-twitter I'd have to mash together the search results into an anonymous object and JSON serialize it back to the browser...right?
In addition, to solve the rate-limiting issue, it seems like Twitter would like me to make these search requests on behalf of my users, but that will require sending them through the oAuth authorization workflow, and then having to store their tokens somewhere to use every time they load a page that shows the "twitter feed". Right?
Finally, part of the functionality built into the existing application is the ability to store a list of tweet ids and twitter user ids and strip those out of the results (if they are offensive, etc).
My brain tells me that there is no way that a simple task such as "show me all tweets with #whatever in them, except for tweet ids 1111212, and 1356346" will require everything I describe above...
What am I missing here?
Edit to Clarify Question
If all queries to Twitter's 1.1 search API must be authenticated, and using ApplicationOnly oAuth authentication is not an option due to rate-limiting, and we don't want to force users through oAuth to capture their tokens, how are we expected to show lists of tweets from the search API in an auto-update jquery-like fashion?
The only option I've found is Embedded Timelines (unless you want to build your own server-side solution with caching, etc):
https://dev.twitter.com/docs/embedded-timelines
Related
Ok so I think I've settled on choosing BLAZOR for my upcoming project. But first I need to do something that is seemingly very basic.
For context, Blazor Server side will be how I interface with my SQL Server dB, I want "individual accounts" mode to be the way users authenticate. I'm using net 6.0,almost all tutorials out there seem to be net 5 since they all still have startup.cs files. Ok, but I also am creating a parallel app that is NOT a website, but I want it to grab data from the same database via routes after authenticating.
For example, website.com/api/data?variablestograb as a GET would send me some json data.
OK that being said, how do I login programmatically from an outside app? If you must know, the outside app is part of Unity C#. But that doesn't matter so much, what itll do is use a post call to login in via the api routes. Something like
Website.com/api/login?un=blah&pw=haha
This will generate a cookie and I can grab it with the session data and I'll use this with every get call hence.
Just using the basic templates, Blazor server net 6.0 with individual auth, how do I set up such a route? Looking at the files, I'm at a complete loss on how the login pages are actually passing data around.
Thanks!
Update: the specific ask is exactly how do I modify the Blazor Server Net 6 Individual Accounts template to allow me to authenticate a user via an external access api? My thought would be to reference the route above for /login/ but that might not even be the best practice. But even if it is, how exactly and where would I update the template to make this happen?
(I have a feeling it's pretty basic to do, but I've been reading tutorials for weeks now and they're all just talking about internal authentication and verification within each Blazor component. I basically want an external program to also be able to "drive the car" remotely, but first it must authenticate.)
If you're building an API for this from scratch, then it seems like you have the right idea, no matter what happens, you're going to send the cookie to be website every request or at least a session id which contains all the information provided. From a database perspective maybe create a session table which then contains all the info you want and also can be easily found. That's a way for you to create a cookie for client server communication, however this is from my limited knowledge and may not be the best way.
I'd recommend hiding information like keys in the header to prevent exposure, looking at other APIs like the Spotify API you can see they set the authorisation bearer.
Exposing all the information for the credentials in the URL for what could be sensitive database behaviour may not be the best. You can hide the information in the header for every request you make.
Maybe have a default controller that obtains the user information before handling any specific requests and making it accessible to your other methods/requests?
The basic process for any external authentication is:
Redirect to the external log in page.
External Provider does it business.
External provider posts to a page on your site with the authentication information included - normally security info in the header or a cookie.
The Blazor app reads the authentication information with the AuthenticationStateProvider.
Normally you just need to write a customer AuthenticationStateProvider and code to redirect if the user is not authorized. This may be a manual button in the top bar, a you aren't logged in page with a button to log in, or an automatic redirect to the provider. The return for the provider is either your landing page or some other page to tell them they logged in successfully.
The custom AuthenticationStateProvider replaces the standard one in DI services and provides the security information to the Authorization components.
Search for "blazor custom authentication provider" will get you lots of good resources.
I have website had built by using ASP.NET c#, my website contains page called my tweets page to display all my tweets from my account on twitter.
I seen many ways but all ways need authentication step , so it bad solution, I am searching about way do what I need, without need authentication step.
Summary:
I am looking to get posts from timeline as data or Rss to make customization for it in my website ,without need authentication step.
If I understand correctly you want to display your tweets on you asp.net page.
You can do this by simply creating a widget and loading in on your page. this is a very simple process involving simple html and java script. Twitter will take care of the rest.
Below is the link
embedded-timelines
no authentication is required.
One small correction, you can display a maximum of 20 tweets at once, after that user needs to click on load more to get the some more appended below.
I've been following this question to retrieve the twitter feed for a particular user Authenticate and request users timeline twitter api 1.1 which is working as expected, the issue I now have is trying to style it to make it look like the twitter feed, the reason we are doing this on the server is because we have a database with all our tweets in so instead of making calls to twitter we have decided to call our database and pull them through. This was implemented and followed through just encase twitter decided to update there API which may result in our feed working (management didn't want to take that chance.)
I have spent some time today trying to find a possible solution to see if this has been done already, I'm aware people have provided server side code to retrieve the tweets but I can't find an example of passing the tweets to the view and displaying them.
I am working on a C# WebApi/MVC project that has a rather large workflow process for creating a user and placing in their required information.
There is about 10 major steps involved, in which it could technically take a user hours to fill out.
The first step takes standard basic information such as username, password, email, name, address etc.
What I would like to do is after this first step is successful, send a rest call that will create the basic user in the user table, and then prepare a session for the further steps in which when any field is filled out in the next steps, it will automatically send an ajax call and update the field in the database.
While this all sounds easy and simple in theory with the use of sessions, which I could do in MVC, I want to do this in WebApi with REST in which REST is supposed to be STATELESS.
Has anyone come across similar issues, and if so what do they recommend as an approach? The options I can currently think of are:
-Ditch the REST for standard MVC for this process and leave WebAPI for only Reads instead of Writes as the only Write process is the inital creation of users/accounts.
-Using Authentication tokens? But can this handle this process successfully?
-Once the user is created, take the username/password for every REST call as the auth to the WebAPI? Store the User/Password in MVC session and directly call the API from MVC, mobile applications would just store the username/password in the application and call the WebAPI (I think this is the most appropriate)
Can anyone tell me if any of those options are the best practice, or does anyone have a better best practice/process for these things? I would prefer to write things once to cover Web and Mobile as much as possible rather than having to duplicate processes.
Thanks in advance!!!
I would consider to modify regular WebAPI OWIN register flow.
Collect basic user info and post to Web API via Ajax. If succeeded -
send OWIN token back to the caller in HTTP header.
Proceed to extra
steps for user info updates (via HTTP PUT for example) and put the
token in authenticate header. Mark WebAPI update procedure with
Authorize attribute.
This blog post could help to setup WebAPI to issue and accept bearer tokens.
Basically we have an iOS app and also a Server application. iOS app would like to get some search result for the end user from SharePoint, so iOS app would submit search request to our server application which would perform the search by using web services (client API) on SharePoint by using a system account. The problem for us is to how to do the security trimming of search results for end user on iOS app.
We could send up the end user's user name and password from iOS app to our server and use that credential to call the search web services, however it is not desirable to do so. I also looked the custom security trimming (CST, Trim SharePoint Search Results for Better Security at SharePoint, it looks like that it won't solve our problem since at ISecurityTrimmer2:CheckAccess method, there is the claims for user who performed the query which is a system user, however we would need to be able to call our application back to find out the real user which seems not practical here:
public BitArray CheckAccess(IListdocumentCrawlUrls, IDictionarysessionProperties, IIdentitypassedUserIdentity)
Any other thoughts about how we could implement the trimming here for our situation? It is really appreciated for any suggestions.
By the way, the iOS app does use the SharePoint Web Services directly, however we want to avoid that since we want the API for search to be generic and not be limited to SharePoint, we are also thinking about sending the authentication header/cookie from iOS app to server for search, however it seems to me that it might not be a good idea and could be think of a security hack.
Update 1:
based on this post: Security trimming in search web service and Creating a Custom Pre-Security Trimmer for SharePoint 2013, there is ISecurityTrimmerPre which we could add more claims to the user, in theory, it could call back our web services to add the claims the correct end user although I don't really know how it would know which end user this search is for if there are multiple searches going on the same time. Another worry is that it seems that we would affect general SharePoint search as well which we don't want to do since we are adding ourselves to the search query pipeline.