I basically have the same question as what is detailed here: Login redirect with asp.Core 2.0 and React. But that post never got an answer.
I've searched quite a bit and pretty much my problem is also touched on here here: https://github.com/aspnet/JavaScriptServices/issues/1440
I want to create a react front end application, but use .net core for the backend. I've used the .net core template with react redux as my boilerplate. I've also configured the .net identity on my backend. So I can actually use [Authorize] on my api calls and it works. By this I mean that if someone is authenticated the api returns data and if no one is authenticated it returns whatever the default redirect page is. I can confirm this by looking at the response on my chrome debugger and I see that it is showing the html for the register page which I've defaulted my login path to in configureapplicationcookie options.
The boiler plate is setup to serve up pages from the react client folder and uses react router. Therefore, I cannot set up any links to pages on my server. However, I'm able to manually navigate to my server pages for example /Account/Login and successfully login. My api calls through the links on the react front end then seem to work just as I would like.
What I would like to do is:
make calls from my react application to my server api
upon unsuccessful access to any api endpoint, redirect the user/request to my register page on the .net core server
have the user register and/or login and then redirect them to the route they came from through the react application.
Is this possible? Is it advisable?
I understand that you can manage all this on the front end using IdentityServer as detailed here: http://docs.identityserver.io/en/release/quickstarts/7_javascript_client.html. However, if all the infrastructure can be quickly spun up in .net and I can leverage the authentication templates, then I want to experiment with that setup and save time. Plus if this is feasible, why bother doing the setup on the front end using a 3rd party login provider? What am I missing?
Related
Use case
I am creating a paid blog website, where people can pay to bloggers to see their blogs.
Solution i Chosen
I have chosen NextJS to build static content(SSG). With fallback option, static content can also built after site is deployed.
Problem
Now, the problem is authentication. We can not authenticate any incoming request on server like SSR.
The only way to check authentication is present on client side. Use useEffect hook to check if the current user is authenticated or not.
But, the problem with this approach is that, any user can disable javaScript on client side to view the content.
Is there any way to authenticated SSG page request on server side.
I don't want to use SSR because increased cost.
You can you use a service called Auth0 to implement static site authentication. It is free up to several thousand requests per month and has React components you can use. Make sure to follow the tutorial for auth0-react and NOT nextjs-auth0 (this is for SSR).
Here is the link to Auth0: https://auth0.com/
You could return null if the user is authenticating on SSG. If you're not loading any content via an API, then the user would be able to see it in the code (but not many users would be doing this). There is the option of Vercel Edge Functions now if you haven't managed to fix this issue yet.
I’ve been using Auth0 in my React web app. I also have a rule that works with new user sign ups. In my web (React) app, I use the Lock library and everything works fine.
Now, I created a React Native mobile app and because I have a custom login/sign up UI, I had to use the API method as opposed to using an Auth0 library such as Lock, etc.
My SignUp API calls work fine and create new users but my rule is NOT working with API calls. I checked to see if rules apply only to my web app but I don’t see any setting for that so I assume all rules should work for all apps that appear on my dashboard – including my new React Native mobile app.
The rule I created on Auth0 creates and assigns a new my_app_id to the new user. This rule has worked flawlessly with all sign ups coming from my web app which uses the Lock library but it doesn't seem to be firing when a new sign up comes in through the sign up API end point.
Is there anything I need to do so that my rule will work with my API calls?
Rules only run after a successful authentication event. This would not include a successful signup endpoint call, where no credentials are authenticated.
The recommended way to hook to a signup would be through a registration hook.
I am trying to authenticate a user inside a desktop application using the web api. I am not using a browser, I am using straight up GET and PUSH calls to the endpoints of the Spotify servers. Immediately I ran into some problems. It appears that upon the initial GET command to "accounts.spotify.com", the returned response includes HTML with a javascript function that runs and is responsible for dynamically generating HTML that you see on the initial login page. If you look at the Javascript function, it is clear that this is what is going on, however, you can also see this code is obfuscated and not meant to be used by us, the developers! (Link to Javascript code here for reference: Javascript function)
So my question is, while I can probably reverse engineer the code to get this working, would this be against the Spotify developer TOS?
Thanks!
Spotify's authentication happens through oauth, and a big part of user authentication as per the oauth rfc is where the user delegates permissions to your app to carry out API calls that affect their account, or return information about them. That's the web page you're seeing - it must be presented to your users so that they can delegate permissions so that Spotify can give your app an access token. It doesn't necessarily need to happen in a browser - it can happen in a web view inside your desktop application - but it does need to be loaded over https, and your application must not alter or reverse engineer the Spotify permissions delegations page.
As you correctly guessed, reverse engineering any Spotify APIs is against terms of service.
For more information on authorization on the Spotify platform, I'd recommend having a look at this guide.
Hope that helps! Please ping me if you have any more questions.
Hugh
Spotify Developer Support
I'm trying to authenticate a desktop application with OAuth. I already asked a question, but I deleted it as I discovered that the method was obsolete (integrated web view).
The idea is to open the browser and then have the page call back my application with a custom:// URI scheme.
Of course it doesn't work, Google asks that the scheme contains a dot (like com.org.myapp), but the native app can only have a fmp:// uri scheme, which I can't change.
The documentation doesn't mention anything, and I can't create a local temporary server.
1- Can I use the fmp:// scheme as a callback in any way?
2- If not, is it possible to redirect the call to another centralised web server? Everything I try generates a 400 error on the google page, saying "redirect_uri_mismatch" or similar stuff.
As stated in the comments above, the only solution is to create an intermediate web server that serves a page which then opens the URL. OR creates a record in the database with the authentication code.
I am using MVC4's WEB API to expose a controller.
Initially I created created a MVC4 WEBAPI project, set the project not to open any web page, wait for an external app to call the URL (WEB API). The project in VS2010 is set to run from IIS7 Express, not VS2010's Dev Server. This works OK, the browser prompts me to down load a file. Which is OK for me, as the browser does not know what to do with the returned data (RAW TEXT).
Next, I created an AREA in the MVC4 project area, then added a controller (WEB API type).
Then I once again ran the project and in a browser entered the the URL (WEB API). And it fails.
Ed.
The DefaultHttpControllerFactory doesn't work with Areas by default. To get this functionality you have to write your custom HttpControllerFactory.
You can find how to do this at the post How to create HttpControllerFactory to support Areas
While it is possible to place WebApi Controllers in different Areas, ASP.NET MVC 4 RC will still treat these ApiControllers as if they all reside in the same namespace. This is a limitation of the DefaultHttpControllerSelector, which is responsible for selecting the appropriate ApiController.
Fortunately, you can inject your own implementation of this class. In fact, I've already encountered this very issue and written an "area aware" HttpControllerSelector. You can find a blog post of mine about this issue and its solution here:
http://blogs.infosupport.com/asp-net-mvc-4-rc-getting-webapi-and-areas-to-play-nicely/