Authentication works fine, except on first page load i.e. SSR. When I check my console.log I see that the console.log from my middleware is always executed at SSR level, eventhough I added ssr:false in my config.
What I did was this:
In nuxt.config.ts I added
{
src: '~/plugins/authenticated.js',
mode: 'client'
}
This code is executed successfully, I can see this by checking my developers console's "vue plugin".
In my "component / page" I added a middleware:
export default {
middleware: [
'authenticated'
]
}
When I run the following code in my middleware, it always shows "false" eventhough in the store the value is set to true.
console.log(store.state.users.logged);
It's driving me nuts, can someone tell me how to get middleware working on first page load? we must have SSR because we need SEO et cetera, but we also do need middleware to work.
Using the latest Nuxt en VueX versions (same for Axios).
I had the same problem and I solved it with a mixin. Mixin with the mounted method is only runs on the client side. I hope I have helped you
Related
I have the following setup
/template. Loads a page that shows all the templates owned by the current user.
/template/new. Loads a page that allows the user to create a template and save it.
/api/save-template. Receives the frontend call made from /template/new and handles storing it on the db.
With those routes, a typical use case is the following:
User ends up somehow (irrelevant) on /template/new.
User creates a template and hit "save". A spiner shows up while saving happens.
Template payload is sent via POST HTTP request to /api/save-template.
/api/save-template route handles the saving successfully and responds with a status 200.
The spinner finishes and the user is redirected to /template, where the newly created template should hopefully show up.
The problem here is on point 5, where in some scenarios, the newly created template doesn't show up. Here's what happens on different scenarios. The app could be running either using next dev, next build && next start, or deployed on vercel. The database could either be hosted locally on docker, or on the cloud using supabase.
db \ app
next dev
next build...
vercel
docker
✅
✅
haven't tried
supabase
✅
✅
❌
One thing to keep in mind, which might be related to the reason this is not working, is that the redirection is made on the frontend using router.push('/template').
I'm also checking on the client side what templates are available when reaching point 5. I've confirmed this is not a db delay issue because the templates are found by the client. For those checks I'm using the following code:
useEffect(() => {
const checkSupabase = async () => {
const templatesResponse = await supabase
.from<Template[]>('Template')
.select('*')
const templates = templatesResponse.data
console.log('templates found from useEffect')
console.log(templates)
}
checkSupabase()
}, [])
And the last thing I want to point out is that the logs I get from vercel make me think the getServerSideProps is not called. I'm logging templates found from getServerSideProps to see what's available on that function. I see the log before creating the template (time 21:31:24:00), and then the /api/save-template being hit (time 21:31:47:11), but I don't see the second request to /template after the redirect. The logs –note the order is newest on the top– are:
21:31:47:11 - [POST] /api/save-template
21:31:24:00 - [GET] /template
templates found from getServerSideProps
[]
Questions
How is it that I don't see a second log for [GET] /template or the templates found from getServerSideProps log? Is it not being fired?
If getServerSideProps is not fired, how come this works when the app is running locally?
Is there a consistent solution for this use case? I guess it must be quite common to want to see recently created data.
Thanks!
I'm trying to use keycloak with a react app, this is my current client configuration...I did this inside the master realm
this is my keycloak config
export const keycloakConfig = {
"realm": "master",
"auth-server-url": "http://localhost:8180/",
"ssl-required": "external",
"resource": "demo",
"public-client": true,
"confidential-port": 0,
"clientId" : "demo",
"url" : "http://localhost:8180/"
};
I based my code on this repo
now...I can login without problems in my app, and the displayed url is this
http://localhost:8180/realms/master/protocol/openid-connect/auth?client_id=demo&redirect_uri=http%3A%2F%2Flocalhost%3A3000%2F&state=ba9daf04-ffdb-4ad3-b912-8be846f0684b&response_mode=fragment&response_type=code&scope=openid&nonce=558d71b7-2c66-44f8-9297-84694dc571a8
but when I try to logout I get a message
Invalid parameter: redirect_uri
the logout url is this
http://localhost:8180/realms/master/protocol/openid-connect/logout?redirect_uri=http%3A%2F%2Flocalhost%3A3000%2F
I'm not sure if my client config is correct because this has several missing parameters in almost all tutorials that I've found
Do you know what could be the problem here?
thank you guys
From the Release Notes:
OpenID Connect Logout
Previous versions of Keycloak had supported automatic logout of the
user and redirecting to the application by opening logout endpoint URL
such as
http(s)://example-host/auth/realms/my-realm-name/protocol/openid-connect/logout?redirect_uri=encodedRedirectUri.
While that implementation was easy to use, it had potentially negative
impact on performance and security. The new version has better support
for logout based on the OpenID Connect RP-Initiated Logout
specification. The parameter redirect_uri is no longer supported;
also, in the new version, the user needs to confirm the logout. It is
possible to omit the confirmation and do automatic redirect to the
application when you include parameter post_logout_redirect_uri
together with the parameter id_token_hint with the ID Token used for
login.
The existing deployments are affected in the following ways:
If your application directly uses links to logout endpoint with the redirect_uri parameter, you may be required to change this as
described above. Consider either removing the redirect_uri parameter
entirely or replacing it with the id_token_hint and
post_logout_redirect_uri parameters.
If you use java adapters and your application does logout by call httpServletRequest.logout(), you are not affected because this call
uses the backchannel variant of the logout endpoint and that one was
not changed.
If you use the latest javascript adapter, you are also not affected. However if your application uses an older version of the
JavaScript adapter, you are affected as this adapter uses the variant
of the logout endpoint with the deprecated redirect_uri parameter. In
this case, you may need to upgrade to the latest version of the
JavaScript adapter.
For the Node.js adapter, the same guideline applies as for the JavaScript adapter. You are encouraged to update to the latest version
as the older version of the adapter uses the deprecated redirect_uri
parameter. With the latest Node.js adapter, you are not affected as
long as you use the logout based on the /logout URL as described in
the documentation or in the Node.js adapter example. However, in the
case when your application directly uses the method
keycloak.logoutUrl, you can consider adding idTokenHint as the second
argument to this method. The possibility to add idTokenHint as second
argument was newly added in this version. The idTokenHint needs to be
a valid ID Token that was obtained during the login. Adding
idTokenHint is optional, but if you omit it, your users will need to
confirm the logout screen as described earlier. Also they will not be
redirected back to the application after logout.
There is a backwards compatibility option, which allows your
application to still use the old format of the redirect_uri parameter.
You can enable this parameter when you start the server by entering
the following command:
bin/kc.[sh|bat]
--spi-login-protocol-openid-connect-legacy-logout-redirect-uri=true start
With this configuration, you can still use the format with the
redirect_uri parameter. Note the confirmation screen will be needed if
the id_token_hint is omitted. Warning The backwards compatibility
switch will be removed in some future version - probably Keycloak 21.
You are encouraged to update your clients as soon as possible as
described above rather than rely on this switch.
I've got the same problem already for hours. The only way I found a workaround is manually sending the user to:
/realms//protocol/openid-connect/logout
I started using Keycloak 18.0.0 since a few days and I cannot find any other solution for this problem. I guess it's only happening to when using the newest version. Maybe we should read the documentation better.
For last Keycloack versions you have to redirect explicitly to
https://you server url/auth/realms/matrix/protocol/openid-connect/logout
This issue comes when the keycloak is upgraded to version 18. So we also need to upgrade Keycloak JS & keycloak-angular package.
https://www.npmjs.com/package/keycloak-js
https://www.npmjs.com/package/keycloak-angular
Rest everything will be similar
Keycloak inserts session_state, state and code in url fragment params.. sometimes after successful login these remain on the url...
Or, when alternate routes are clicked in the app, these appear again.
Unnecessarily exposing the internals of keycloak params to users.
Is there some solution to not have these appear or delete them?
e.g. http://localhost:3000/home/#state=e625140e-c4f9-4500-858e-32c80e89f8a9&session_state=445229c3-d7eb-46e9-bfba-3339253dd17e&code=af0abde4-a60d-4f34-a101-8db5c76546b9.445229c3-d7eb-46e9-bfba-3339253dd17e.59915134-a59b-4ffb-878a-d02e7e84f2dd
Update:
with more tests narrowed down the issue to occur when
anything on the keycloak instance is touched. e.g. keycloak.token
any function call of keycloak is invoked... then after that these params get added and removed for every url route thereafter...
e.g. await keycloak.updateToken()
Keycloak Sever and js lib Version : 9.0.2
It is not a Keycloak issue. That's how used login flow works (maybe you need different flow, which will be more suitable for your use case). Your app code (used OIDC/OAuth library) should "clean" URL fragments. Cleaning can be: exchange code for the token (in this particular case), remove URL fragments, clean browser history, etc.
I'm using FlowRouter. If I start on the homepage everything works well. I can work through the routes (change the pages) without problem. However, if I hit refresh in the browser, I get a series of errors. My url looks like this:
/story/586d536e34821281735b53a4
The ID is being returned in console under the following method:
Tracker.nonreactive(function(){
I think the subscription is being completed, so I'm a little confused as to why reloading a url is different than loading from the home page.
What am I not understanding here?
Reloading a url will make a HTTP request to server to get all the application source. Whereas navigating to a route from another one does not make any HTTP requests to get the application source because they are already available (they were loaded from the previous route), in this case the router will just get the appropriate content and render on the page. This is normal behaviour for Meteor apps and all other single-page apps
The error you encounter is because your data is not yet available on client, to fix it you could simple use a placeholder if the value is undefined.
I am trying to access Soundcloud from a local HTML page on my laptop. I am stuck at the part of hosting "callback.html" as a redirect_uri. The script I am trying to run is the basic Authenication JavaScript from the Soundcloud documentation page:
<script src="http://connect.soundcloud.com/sdk.js"></script>
<script>
// initialize client with app credentials
SC.initialize({
client_id: 'my_client_id',
redirect_uri: 'http://127.0.0.1/Users/Maria/Documents/SoundcloudClient/callback.html'
});
// initiate auth popup
SC.connect(function() {
SC.get('/me', function(me) {
alert('Hello, ' + me.username);
});
});
</script>
This script gets me to the connect pop-up when I launch the page in Chrome and Firefox.
But, once I have logged in as a Soundcloud user, I get the following error:
Oops! Google Chrome could not connect to 127.0.0.1
If I change my redirect_uri to localhost I get the same error.
If I try:
files:///C:/Users/Maria/Documents/SoundcloudThinClient/callback.html
I get a similar error.
I also tried:
ocalhost:3000
and:
localhost:8080
even though I'm not sure what would be listening on those ports.
So, basically, I'm asking what path do I put for callback.html in order for this to work?
I confess I don't know how the redirct_uri actually functions. I looked at the Oauth pages for it, but I don't understand them. I am beginning to think that I can't simply create an HTML page, paste the JavaScript, create a callback.html file and have this work, even though the SC documentation seems to say that this is possible. If so, what steps am I missing?
I am beginning to attempt this. I believe you have to go to the developer site and sign up as having an app. The redirect uri is asked for and the form gives you an API key you can use in your app.
I'm using drupal so, perhaps adding the oath module and using Php to add the api key might work well.
I had the same problem and I think I solved it.
Morning-after-edit: I posted this dead-tired after working towards a solution through the night. Now, the day after, I realize that you were speaking about the general problem, whereof I face a very particular instance. The following only applies directly to registering soundcloudlabs' soundcloud-group-recorder: https://github.com/soundcloudlabs/soundcloud-group-recorder. There is probably a more general principle lurking behind there, though:
First: yes, you do have to register the app as your own at Soundcloud. At least I presumed so. And doing that, you must register correctly where on your server you will place the callback.html file. Take the ClientID assigned to your app and use that in the API intialize procedure.
Now, I'm a novice and know very little coding. But I started looking around in the main file, application.js.
At the top of the file there are two instances of client_id and redirect_uri each. I'm not sure if that serves a purpose or if one is technically superfluous. Through trial and error I found out that replacing the second instance of each with my own data worked.
Then there is groupId and groupUrl, both of which should contain your info, within quotation marks.
After a lot of trial and error, still having trouble getting the thing to run, I looked around and saw that, whereas early in the file, client_id was hooked within SC.initialize, redirect_uri was not. Under the line:
client_id: CLIENT_ID
I added:
redirect_uri: REDIRECT_URI
– with a customary comma in between. And that's it. It runs.