I have a question regarding the possibility to change the backend occ endpoint for the login.
In the default behavior, an auth object is created in local storage.
I changed in the app.module the default login: '/authorizationserver/oauth/token', to a different endpoint (/ourowntestserver/oath/token/test). After the change, the backend-side works as it has before, but on the front-end side, the auth object is not available in the local storage anymore.
In the Spartacus source code I can see an OAUTH_ENDPOINT with the same endpoint '/authorizationserver/oauth/token', used in an open-id-token.service, but I am not sure if that service is responsible for actually saving the token and if I have to extend it in the storefront app along with its store(actions, effects, etc.) too.
Are there any other changes that have to be done for this to work, or am I doing something wrong? Is it possible that the issue could be still back-end related?
Any help would be appreciated. (edited)
I would start by inspecting ngrx actions in devtools. Look for LoadUserToken and LoadUserTokenSuccess and LoadUserTokenFail actions. Look at their payload if everything there looks ok. Maybe the structure of response is different than the one returned from the default hybris OAuth server. Then you might need to create your own effect and handle the response a bit different than we do this by default.
The OAUTH_ENDPOINT is not currently customizable and it is being fixed right now for the 3.0 release. It'll have new auth module structure and allow for easier replacement of OAuth server.
open-id-token.service.ts is only used with Kyma module when you also need apart from access_token the id_token from OAuth server.
Related
I have an xAPI content made by storyline I want for the statement to be sent to a webapp instead of the LRS.
this webapp is developped using laravel, and user should be authenticated with email and password to use it.
what I did to send the statement to this app:
1.in the webapp I created an API endpoint route that use POST method.
2.in the xAPI wrapper I changed the endpoint in the configuration to the route I made in the webapp.
const conf = {
"endpoint":"here I added my api endpoint route of the webapp",
"auth":"Basic " + toBase64(""),
}
now whith any interaction with the content where a statement should be sent the request making cors error like in the picture down, I think this is authentication error, how can I add my authentication credentials to the xAPI wrapper?
Your non-LRS LRS is probably not handling preflight requests which are necessary for CORS handling. Most common LRSs will handle those requests appropriately since they expect to be accessed from additional origins. See https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#preflighted_requests
Also note that you'll likely run into issues unless you also handle state requests.
Additionally unless you are requesting the credentials from the user during runtime then hard coding the credentials into the package isn't a great idea from a security perspective.
For the first time, we are developing a new project that needs to support the browser (a website) and a mobile app built on react-native.
We have plenty of experience developing for the web, but little to no experience in the mobile app world.
We are now defining our API and trying to make it work for both platforms - This will be a basic JSON API, running on Flask. The API will have some public endpoints, and some protected ones as well (that require auth). We want a cross platform auth solution.
Typically, for the web, we have always relied on cookie based sessions (encrypted) that frameworks like Flask provide. We have been successfully using these in various scenarios: loading HTML templates directly from the web framework, or even when the frontend application runs on React (same domain + HttpOnly + secure cookies).
The introduction of react-native could potentially bring some new challenges, and some of our developers worry about not being able to continue to use our typical session based cookies - They are advocating to using something like JWT for authorization, for both the browser and app (and yes, I know that we can't compare sessions to token based auth).
I'm not a big fan of token based authorization (for a number of reasons, could entertain that conversation if anyone wants to waste some time...), and I can't seem to understand why we shouldn't stick to our normal encrypted "Cookie" value.
Here is how I imagine this could work, based on using the Flask cookie session:
A user hits /api/login with some credentials
The endpoint will validate the user and return back whatever response + the Set-Cookie header with a value of session=<encrypted string>
Any further requests from the browser/app would send back the cookie value again.
Essentially, nothing would change for typical browser implementations, this is how browsers work by default.
The react-native documentation mentions a few issues with cookie based authentication: https://reactnative.dev/docs/network#known-issues-with-fetch-and-cookie-based-authentication
From what I can gather (my knowledge is extremely limited on this subject), react-native might not always respect the Set-Cookie header. Which is OK - we would just have to make sure to send back the expected header with any further requests.
This, in theory, would fulfil our requirements.
I'm looking for feedback on my "solution", am I missing anything? Did I get HTTP completely wrong?
React Native actually provides networking similar to that of websites developed with basic JavaScript, which also supports cookie based authentication, however there are some serious caveats as mentioned in here
The following options are currently not working with fetch
redirect:manual
credentials:omit
Having same name headers on Android will result in only the latest one being present. A temporary solution can be found here:
https://github.com/facebook/react-native/issues/18837#issuecomment-398779994.
Cookie based authentication is currently unstable. You can view some of the issues raised here:
https://github.com/facebook/react-native/issues/23185
As a minimum on iOS, when redirected through a 302, if a Set-Cookie header is present, the cookie is not set properly. Since the redirect
cannot be handled manually this might cause a scenario where infinite
requests occur if the redirect is the result of an expired session.
Therefore, I would advise against using it as it is unstable and might give you a hard time dealing with it
I also suggest looking into frameworks that handle authentication for you, such as auth0
Hope you find this helpful :)
I want to understand whether nuxt-auth uses serverMiddleware and if not how can i implement one. I want to make my admin panel really secured, I have my backend secured however even if someone manages to overcome auth middleware on the frontend, which won't be that difficult(if auth Module uses client-side middlewares), I don't want nuxt to provide him/her with the layout and all pages even though I know that he/she is not going to be able to do anything because my routes on the backed require token verification and account data. If you can, please provide some info on the subject. Thanks!!!
So in short you cannot use the middleware provided by the #nuxtjs/auth plugin as a serverMiddleware, you can only use it as a normal middleware.
But that doesn't mean that it's insecure, normal middlewares actually executes both on server and client side before the page is rendered, so if you want to execute a middleware that will throw a 404 if the user isn't logged in you can do this in a normal middleware too, the serverMiddleware's capabilities are actually limited, you can't access nor the store or any client side information, because you only get (req,res, next) as parameters, and since Authentication is stored in store and cookies you can't make it work in Node.js only. This is a good example of what you can use serverMiddleware for: https://jackwhiting.co.uk/posts/handling-redirects-in-nuxtjs-through-middlware/
If you console.log something in normal middleware you should be able to see it both in your developer console and bash where npm run dev is running, this would mean that first the server executes it and then the client side too.
My Vue.js app which interacts with data via a Node.js backend accesses both sensitive and non-sensitive data. I have been able to protect the API's on the Node server, the ones working with sensitive data (such as updating pricing information) using the google authentication API. This requires a user to have to login with a google account before being able to interact with those API's.
I'm now trying to protect the API's which simply retrieve non-sensitive data (such as Names, descriptions, prices of products I sell, etc.) so that even said API's cannot be accessed directly without some form of authentication. ie. If I used something like Postman to retrieve data from the API directly, without authenticating I would not be able to get any data. However, these API's are accessed from a part of the Vue.app which does not require login. ie. Users on the site may see Product, pricing etc. information without having to login first.
In order to protect these "non-sensitive" API's I would have to pass some "secret" such as an API Key from the Vue front-end to the Node backend. I believe from 2 other posts I've done (here and here) that it isn't possible to pass Environmental variables into a Vue App at run-time (I'm using Vue CLI 3). This leaves me with having to hardcode the API Key into the front-end code which means it is no longer "secret" or secure.
I'm in essence trying to do "Application Authentication" but without the ability to pass ENV Variables in Vue at run-time I don't know how to do this securely.
Everything I read on the internet points to either:
Passing ENV Variables into Vue at build-time (which isn't secure in this scenario); or
That I'm missing something for wanting to pass ENV Variables into Vue at run-time in the first place.
Question: Am I overthinking or overcomplicating things by trying to protect data which isn't sensitive?
One way of doing so is the following:
Upon successful authentication generate a JSON Web Token
Send token back to the client (Vue app) and store it in the browser's local storage
On the API route you want to secure add a function that will check whether the the request contains the token you provided on Step 2. You can send the token as part of the request body or maybe a header.
This is a simple yet effective way of securing an API.
I'm trying to write a new application using the Flattr REST-API version 1 (not the beta v2). The application acquires a request token at first, which seems to work properly. But I run into a problem authenticating the user. The link created for authentication looks like this:
https://api.flattr.com/oauth/authenticate?access_scope=read,click&oauth_token=MY_REQUEST_TOKEN
Clicking the link everything seems alright. Information about the application and the scope requested is shown, but clicking "Authenticate", there's no pin code, but the following error from https://flattr.com/apps/pincode/MY_REQUEST_TOKEN:
Something went wrong. Please try again
BUT now the Application IS in the authorized application list of the user though that doesn't really help if the user can't get the pin code...
The Application type is set to client. It's the first time I try to work with the API so I'm not sure if I miss anything important? Would be grateful for some help.
Just as an update: We finally changed to API v2. Getting Authorization for our application feels a bit clumsy, as we set the redirecturi to some webpage, where we display the returned code and let the user copy&paste it into our client application... we kind of made our own pincode-flow :/
If possible, please use the v2 api, which uses oauth2 + bearer token.
However, the new API doesn't support authentication using the pincode flow.
As stated by Maike this is probably a bug that has surfaced yet again :(
I'll create an internal bug ticket and try to get it fixed.
The pincode isn't a feature planned. You can use the oauth2 "implicit grant" to authenticate the resources owner. This isn't documented at the moment but is possible.
When you do the request to https://flattr.com/oauth/authorize you pass the response_type token instead of code. This will append a access_token fragment in your callback URL. In your http client it might be possible to catch the 302 from our server and parse the access_token from the fragment.
All this requires a http client in your application whom you can control the flow inside your app.