tl;dr: move authentication from useAuth hook to the server side with laravel breeze with next.js?!
The situation
I am using a project setup like the original laravel breeze repo.
It ships with the useAuth hook, which handles the authentication on the client side.
This setup is barely satisfying as it does not utilize the server side rendering for all components that need authenticated content.
The Question
How could I provide a way to authenticate the user on the server side to gather all the information possible and render more on the server?
I don't need to get rid of useAuth at all.
My Attempt
I tried to move the hook getServerSideProps but that is not allowed. My knowledge of the useSWR used inside the useAuth is slightly thin.
Related
Never thought I'd run into an issue of having too much documentation! I need help with picking the right information so I can read it, understand it, and follow it.
My scenario:
I have an ASP .NET Web Application that is hosted on mywebapp.azurewebsites.net
The web app has a full REST API at mywebapp.azurewebsites.net/api/v1/dostuff/1
You can go to the site and perform all the CRUD stuff. You can also use desktop application to do the same.
I went ahead and enabled Azure AD authentication in Azure Portal. Now in order to do anything on the website, users need to sign in. It brings up the usual Microsoft Login popup and then upon successful authentication redirects back to the site.
But when it comes to the desktop app, I want the users to be able to use it without signing in. Somehow my desktop application needs to be able to make calls to the API/website and be authenticated!
At this point I am lost if there is something I need to do in manifest file, or in the web app, or elsewhere?
Most I was able to do is get an access token using client credentials/client secret.
I just need to know if what I am trying to achieve possible and which document explains the approach of doing so.
Well the fundamental problem you have is that a desktop app (like any public client) has no way of authenticating itself to AAD in a secure way.
You cannot use a client secret.
It is very easy to grab the secret from the executable, and that is basically your app's password.
You would have to make the API accept calls without authentication pretty much.
If authentication is required for access to the API,
then a user must authenticate in the app.
How can I force a refresh if the person navigates here while logged in. Also, I currently have my data fetching done in getInitialProps but only when req exists (server side). What should I do to make sure if a navigation happens back to this page that it always re-renders server side?
It is not possible to make getInitialProps run only on server side.
From the docs
For the initial page load, getInitialProps will execute on the server only.
getInitialProps will only be executed on the client when navigating to a
different route via the Link component or using the routing APIs.
You can use isomorphic fetch that exists both on server side and client side so you won't care on what side your data gets fetched. Example with using fetch can be found on docs as well
Hope this helps!
I have a cross-site ajax login request coming from a chrome extension to a Meteor app. I am handling this on the Meteor side using Iron-Router and the where:'server' setting. The request comes in fine, but now that I have the request, I want to login the user. How do I do that from the server?
I tried getting around it in a hacky way by redirecting from the server to another router using Router.go('otherRoute', {email:requestEmail, password:requestPassword}) in the action callback but that didn't work because the go method wasn't found. Either way, that seems like a poor solution to this problem.
Roughly speaking, what you will need is more or less a DDP client present on your custom (non Meteor?) website. The features you require are implemented in meteor's livedata package. There's also a node package node-ddp-clinet (server side), which you could probably use as a starting point in implementing your own client.
Once you have a working DDP client, logging in is a matter of calling login method on the server (through DDP of course). Look
here for more details.
I have a system which will update some UI details regarding user notification every X seconds (just like StackOverflow's notification, gmail inbox and so on).
I am planing to have a webservice that will check for new notifications and have it called every X seconds. The fact is: I do not want to make it public for everyone, I want to make it accessible only to my system, so it is the only one able to consume it.
Is there any way to do that? Using a WebService is not required, if you have other approach I would like to hear it.
My system is built using ASP.NET 4.0 and Microsoft's MVC framework. Could I call an action to do that?
My question is similar to this: How do I secure ASP.NET web service to only allow relative path calling?
But as far as I understood the answer, he proposed that the webservice could be turned into an ordinary class method inside the system that is not accessible from outside. This does not work for me because I want to access it from the client side.
Thanks,
Oscar
ps: changing infrastructure configs (ex: hosting it in an internal server) would be hard to do...
EDIT: what I want to achieve with this webservice is to update the notifications number. This should be done without refreshing the page, for this reason I thought about verifying with the server if there are any notifications and, if there are, update the UI.
Edit2: I could transform this webmethod in an ordinary method inside my system, that would be no problem. The question would then change to How do I wire the client to this method? Maybe calling an action using javascript and then inside this action calling the method?
Deploy this WebService on a different web site and then configure this site to be accessible only from IP : 127.0.0.1. Also checkout this blog post - you could install the IP Security and then:
Lastly, to create the restrictions, open up the IIS Manager and select
the website that you want to restrict. Open the IP Address and Domain
Restrictions module, and then in the actions panel (on the right side)
choose Edit Feature Settings.... To only allow local browsing, you
should deny by default. Choose Deny from the dropdown, and hit OK.
Then add your exceptions -- the IP's or ranges that you want to allow
access to. To do that, choose Add Allow Entry... from the action
panel, and add all the exceptions you need.
Now, only applications running on the same web server can access this web service.
I have a flex app hosted on a windows server running IIS. That same server has some rest services that the app interacts with. The rest services have windows authentication so that their urls cannot be called without credentials. The flex app needs to be accessible to the public so its files are accessed by enabling anonymous access. The problem is of course that when the app tries to call the rest services the browser pops a dialog box asking for windows username and pass. I naively hoped that if I set the anonymous access on the flex site to use the credentials of a windows account that had permission to view the rest services that would resolve the matter. I hoped that IIS would see the browser used the proper creds to view the flex app and use those same creds to get the rest services. Wrong, that didn't work.
So is what I want impossible? I'd like to find a way to not force the user to enter windows creds, keep the rest services using windows authentication, and have the flex app able to access the rest urls. Any ideas? Am I missing something? Also, it may turn out that the flex app is running on http and the rest services must be called with https. Does that change your answer? Any thoughts much appreciated.
Flex runs on the client machine, so any calls made to the services will be from there. What you could do is to set up a second web service that runs on the same server under a windows username and calls the first one.
Just remember, the flex app is actually running off of the users local machine. For this reason, all calls will be made from their machine, so you need to setup some sort of authentication for the app to deal with calls.
If you want to read about a good way to pass information back and forth, lookup tutorials on using 'services-config.xml' and start there. You will find a lot of material about alternative ways to authenticate, pass information, and use remote objects.
Hope this helps...