All I'm trying to do here is to be able fetch paypal_api_key from backend api something like:
app.get("/api/keys/paypal", (req, res) => {
res.send(process.env.PAYPAL_CLIENT_ID || "sb");
});
frontend side:
const loadPaypalScript = async () => {
const { data: clientId } = await axios.get("/api/keys/paypal", {
headers: { authorization: `Bearer ${userInfo.token}` },
});
paypalDispatch({
type: "resetOptions",
value: {
"client-id": clientId,
currency: "GBP",
},
});
paypalDispatch({ type: "setLoadingStatus", value: "pending" });
};
loadPaypalScript();
ERROR:
Uncaught Error: Attempted to load sdk version 5.0.343 on page, but window.paypal at version undefined already loaded.
To load this sdk alongside the existing version, please specify a different namespace in the script tag, e.g. <script src="https://www.paypal.com/sdk/js?client-id=CLIENT_ID" data-namespace="paypal_sdk"></script>, then use the paypal_sdk namespace in place of paypal in your code.
at VM827 js:2
at Module.<anonymous> (VM827 js:2)
at t (VM827 js:2)
at VM827 js:2
at VM827 js:2
I've tried this
<script src="https://www.paypal.com/sdk/js?client-id=***"></script>
it works but I'm not interested in passing my api key in plain sight like that
The Client ID is and must be public information, it's required for the script to load. Fetching it asynchronously after page load and using it to load the script dynamically does not in any way hide it; it will be in "plain sight" the moment the browser makes its request and also the moment the resource is loaded. So if that's the reason you're loading the script asynchronously, it does not make any sense; you are accomplishing nothing and should just do what works, ether putting the script tag in your page as HTML or using the official react-paypal-js.
In any case, the cause of your error is you are doing something that loads the SDK more than once. You need to ensure it's only loaded once. (for the rare use case that requires multiple SDKs concurrently, data-namespace is available but this is not your case)
I am using, sails.js to build a REST API. i want to use the first built in template of sails.js.
sails.js template choice
I am having issues with authentication. I can't use post man to sign in nor log in.
I searched a bit and I was able to get the _csrf token inside sails with
<form>
<input type="hidden" name="_csrf" value="<%= _csrf %>" />
</form>
but i couldn't find any route that will deliver me the token as a json so that i can access it form vue.
something like GET : localhost:1337/api/token
{ _csrf: 'ajg4JD(JGdajhLJALHDa' }
can someone help get me on track. i have been looking for a while now.
For frontend
In your frontend you can access the CSRF on the global object inserted by Sails - window.SAILS_LOCALS._csrf.
For testing
In your config/routes.js you will have to add this:
'GET /.temporary/csrf/token/for/tests': { action: 'security/grant-csrf-token' },
Do not let this go to production though. The recommended way for this is to only expose this route during automated tests. Here is some info about testing in Sails.js - https://sailsjs.com/documentation/concepts/testing - Here is my lifecycle.test.js - https://gist.github.com/Noitidart/63df651dc76812da6cb3bfe1ce4e9e0e - You see I expose this route only for my tests, so my production doesn't get this. It's not recommended to test your endpoints with Postman because those tests are ephemeral, your testing work is now gone after you are done. But if you write unit/integ tests, that work testing will stay forever.
If you are using Sails v1
// config/security.js
module.exports.security = {
csrf: true,
};
// config/routes.js
'GET /csrfToken': 'SomeController.grantCsrfToken',
// api/controllers/SomeController.js
module.exports = {
grantCsrfToken: function (req, res /*, next */) {
// Don't grant CSRF tokens over sockets.
if (req.isSocket) {
if (process.env.NODE_ENV === 'production') {
return res.notFound();
}
return res.badRequest(new Error('Cannot access CSRF token via socket request. Instead, send an HTTP request (i.e. XHR) to this endpoint.'));
}
// Send the CSRF token wrapped in an object.
return res.json({
_csrf: res.locals._csrf
});
},
}
// assets/js/some_filename.js
function send_some_post_request(extra_params) {
$.get("/csrfToken", function (data, jwres) {
if (jwres != 'success') { return false; }
msg = {
extra_params: extra_params,
_csrf: data._csrf
};
$.post("doStuff", msg, function(data, status){
});
});
}
Let's say I have a user's account information stored in localStorage (client side). I need my Next.JS app to render the webpage's navbar based on what's stored in localStorage (login or logout button). How can I first obtain the value from the client and then render the page? Or perhaps that isn't even what Next.JS is meant to do?
You can do something like this:
Use a variable in the state to prevent the page from being rendered
Use componentDidMount to load data from localStorage
When data is loaded, setState to allow component to be rendered.
It's a react issue, not a next.js issue.
You could use Conditional rendering for step 1.
Also read up on state here, and lastly componentDidMount.
Update:
Nowadays, I would opt for a React hooks implementation instead, but the idea still stands. useEffect can largely accomplish this with some nuances in some situations.
I also realize that there are some possible caveats with NextJS and SSR logic specifically, so this response may not be sufficient. In such cases, I would also look into some other responses below.
As mentioned at https://stackoverflow.com/a/54819843/895245 I haven't been able to truly get localStorage before the first render, only show a fallback page until that happens.
The fundamental issue is that Next.js maps one URL to one pre-render. And React hydration requires the initial server HTML to match the JavaScript structure:
React expects that the rendered content is identical between the server and the client. It can patch up differences in text content, but you should treat mismatches as bugs and fix them. In development mode, React warns about mismatches during hydration. There are no guarantees that attribute differences will be patched up in case of mismatches. This is important for performance reasons because in most apps, mismatches are rare, and so validating all markup would be prohibitively expensive.
That quote is not very clear if text-only changes work or not but the minimal test below shows that it raises a warning in that case, so you don't want to use it.
Therefore the only sure-fire way it to use useEffect to update the page afterwards.
However, when I've tested, the correct render with localStorage shows up so quickly that the intermediate one it is not noticeable at all, I'm not sure it even happens. The only problem is if you make different API calls on each case, see section "Differentiate between "not logged in" and "haven't decided yet" to avoid doing extra API calls" below for an example of that.
What I would like to do is to give a slightly more concrete idea about what was mentioned in that answer.
SWR example
Here is a complete runnable example where the navbar shows login status: https://github.com/cirosantilli/node-express-sequelize-nextjs-realworld-example-app That repository is a fork of this one, both of which are Next.js implementations of the awesome realworld project.
The fallback in that case is just the signed out view of the blog pages, which already contain the key information users are likely to want to see, and can be cached e.g. with ISR.
That demo uses SWR to make the code slightly simpler. The key parts are:
navbar code
login code
The key parts of the code there are:
navbar:
import useSWR from "swr";
const Navbar = () => {
const { data: currentUser } = useSWR("user", key => {
const value = localStorage.getItem(key);
return !!value ? JSON.parse(value) : undefined;
});
login:
import { mutate } from "swr";
const LoginForm = () => {
const handleSubmit = async (e) => {
// Get `user` data structure from API.
mutate("user", data?.user);
We see that when the user logins, we call mutate on the "user" global identifier.
This redraws all components that contain that hook, which includes the navbar, as it setup the hook with the useSWR call.
This way, login first redraws the navbar, and then redirects you to home, so that the home page will have the redrawn navbar immediately. Without mutate, only the page body would redraw, not the navbar.
With this setup:
if you put a console.log(currentUser) just below useSWR, you see that it gets called twice.
So what happens is that it first returns immediately with a cached value (undefined) and the first render starts.
It then starts an async call to the cache, and when that returns, the hook triggers a re-render of the component, and the print happens again with the current user value.
This only happens on initial hydration during refresh/first hit. During internal page changes, there is just a single render.
All of this happens so fast that I can't see the page draw without hte local storage at all, not even with the Chromium debugger timeline frame inspection.
if we add a 2 second delay to the localStorage getter however:
const { data: currentUser } = useSWR("user", async (key) => {
await new Promise(resolve => setTimeout(resolve, 2000))
const value = localStorage.getItem(key);
return !!value ? JSON.parse(value) : undefined;
});
we do observe an intermediate page state with the user logged out, so it could in theory happen.
How it would look like without SWR
Of course, we wouldn't need to use SWR to achieve this.
The SWR documentation gives us the rationale of how thing would look like without SWR https://swr.vercel.app/getting-started to motivate their library.
You would either need to move the state up to a common parent of the login form + navbar, or you could use Context.
function Page () {
const [user, setUser] = useState(null)
// fetch data
useEffect(() => {
const value = localStorage.getItem(key);
const user = !!value ? JSON.parse(value) : undefined;
setUser(user)
}, [])
// global loading state
if (!user) return <Spinner/>
return <div>
<Navbar user={user} />
<Content user={user} />
</div>
}
// child components
function Navbar ({ user }) {
return <div>
...
<Avatar user={user} />
</div>
}
function Content ({ user }) {
return <h1>Welcome back, {user.name}</h1>
}
function Avatar ({ user }) {
return <img src={user.avatar} alt={user.name} />
}
As mentioned at What is difference between lifecycle method and useEffect hook? useEffect is the hook analogue to componentDidMount.
Checking typeof localStorage === 'undefined' leads to a warning
React doesn't like that and warns with something like:
Expected server HTML to contain a matching"
as it notices the difference between hydrated and non-hydrated pages: React 16: Warning: Expected server HTML to contain a matching <div> in <body>
Tested on Next.js 10.2.2.
Minimal reproducible example
Just to play with and see exactly what happens:
pages/index.js
import Link from 'next/link'
import React from 'react'
export default function IndexPage() {
console.error('IndexPage');
let [n, setN] = React.useState(0)
if (typeof localStorage === 'undefined') {
n = '0'
} else {
n = parseInt(localStorage.getItem('n') || '0', 10)
}
return <>
<Link href="/notindex">notindex</Link>
<div
onClick={() => {
localStorage.setItem('n', n + 1)
setN(n + 1)
}}
>increment</div>
<div
onClick={() => {
localStorage.removeItem('n')
setN(0)
}}
>reset</div>
<div>{n}</div>
</>
}
pages/notindex.js
import Link from 'next/link'
export default function NotIndexPage() {
return <Link href="/">index</Link>
}
package.json
{
"name": "test",
"version": "1.0.0",
"scripts": {
"dev": "next",
"build": "next build",
"start": "next start"
},
"dependencies": {
"next": "12.0.7",
"react": "17.0.2",
"react-dom": "17.0.2"
}
}
Run:
npm install
npm run dev
Now, if you:
open /
increment
refresh the page
react gives a warning because it notices that the 0 text was changed to 1:
Warning: Text content did not match. Server: "0" Client: "1"
If we click the internal links however to notindex and back, we don't see the warning. This is because hydration is only done on the initial page refresh, further changes are done in Js only.
What we have to do instead is something like this:
import Link from 'next/link'
import React from 'react'
export default function IndexPage() {
console.error('IndexPage');
let [n, setN] = React.useState(0)
React.useEffect(() => {
console.error('useEffect');
setN(parseInt(localStorage.getItem('n') || '0', 10))
}, [])
return <>
<Link href="/notindex">notindex</Link>
<div
onClick={() => {
setN(n + 1)
localStorage.setItem('n', n + 1)
}}
>increment</div>
<div
onClick={() => {
localStorage.removeItem('n')
setN(0)
}}
>reset</div>
<div>{n}</div>
</>
}
Differentiate between "not logged in" and "haven't decided yet" to avoid doing extra API calls
OK, I had another issue: I was making unnecessary API calls, because first the page thought the user was logged out, and then it thought it was logged in, and each of those needed to do different API calls.
Unlike starting to render the wrong page, this would actually have server load consequences, so it was not acceptable.
The solution I used was to differentiate between:
undefined: haven't decided
null: not logged-in
and not make any requests on undefined.
Here's a non-minimized demo:
https://github.com/cirosantilli/node-express-sequelize-nextjs-realworld-example-app/blob/2bbce5199d3a7efa19a3a58426bea25a1cd37579/front/ArticleList.tsx#L33
https://github.com/cirosantilli/node-express-sequelize-nextjs-realworld-example-app/blob/2bbce5199d3a7efa19a3a58426bea25a1cd37579/front/useLoggedInUser.ts
I'll try to minimize it later on.
Another solution: just do SSR
In general, SSR is way simpler than ISR, because you don't have to worry about this get page/ask for data/get data/update page dance from Hell.
ISR is an optimization, and you should only use if there's a proven performance benefit.
Remember that SSR in Next.js is also very data efficient, as Next.js returns only the .json from getServerSideProps on page switches, basically exactly like an API would.
You can then just do authentication from getServerSideProps with cookies, and return the correct page straightaway.
This is how I did it.
const setSession = (accessToken) => {
if (typeof window !== 'undefined')
localStorage.setItem('accessToken', accessToken);
};
const getAccessToken = () => {
if (typeof window !== 'undefined')
return localStorage.getItem('accessToken');
};
Here is where I call them to handle login and to get the access token:
const loginWithEmailAndPassword = async (email, password) => {
const { data } = await axios.post(`${apiUrl}/login`, { email, password });
const { user, accessToken } = data;
if (user) {
setSession(accessToken);
return user;
}
};
const accessToken = getAccessToken();
local storage is not available on the server, there are two options to resolve this
1: create HOC or custom hook to check if the local storage has the data (this is normal react way)
2: you can use cookies to store data on client and server side , which can be then be used getServerSideProps to extract the data and and you can then use this data to display the information accordingly on the initial render.
you can use useEffect hook and useState, so that when component loads, useEffect will fire last, extract data from localStorage and assign it to a STATE from useState.
then you can access your data from useState, states. if that makes sense.
Bottom line, useEffect allows to easily extract data from localStorage, so then you can do what you like with it.
const [userData, setUserData] = useState({});
console.log(userData);
useEffect(()=> {
setUserData(localStorage.getItem('userSession'));
}, [])
The first render which happen on server side can not have access to localStorage and throw the error. To prevent this, add an extra layer of defense with
if (typeof window !== 'undefined') {
// run logic that read/write localStorage
}
Then it should skip the logic when on server and run it when loaded on client side
I am using the Synchronizer Token Pattern for standard forms (useToken = true) but I cannot find any recommended method of dealing with this over AJAX.
EDIT
Since posting this, I have rolled my own solution incorporating Grails existing pattern from above.
In the jQuery ajax I post the entire form (which will include Grails' injected SYNCHRONIZER_TOKEN and SYNCHRONIZER_URI hidden fields) such that the withForm closure can perform as expected in the controller.
The problem is, on successful response, there is no new token set (as the page is not reloaded and the g:form taglib is not evoked) and so I do this manually in the controller calling into the same library as the g:form taglib, and return it in the ajax response, and then reset the hidden field value.
See below:
var formData = jQuery("form[name=userform]").serializeArray();
$.ajax({
type: 'POST',
url: 'delete',
data: formData,
success: function (data) {
// do stuff
},
complete: function (data) {
// Reset the token on complete
$("#SYNCHRONIZER_TOKEN").val(data.newToken);
}
})
in the Controller:
def delete(String selectedCommonName) {
def messages = [:]
withForm {
User user = User.findByName(name)
if (user) {
userService.delete(user)
messages.info = message(code: 'user.deleted.text')
} else {
messages.error = message(code: 'user.notdeleted.text')
}
}.invalidToken {
messages.error = message(code: 'no.duplicate.submissions')
}
// Set a new token for CSRF protection
messages.newToken = SynchronizerTokensHolder.store(session).generateToken(params.SYNCHRONIZER_URI)
render messages as JSON
}
Can anyone identify if I have unknowingly introduced a security flaw in the above solution. It looks adequate to me but I don't like hand rolling anything to do with security.
Nice!
IMO, you'd better reset the token at the same time.
SynchronizerTokensHolder.store(session).resetToken(params.SYNCHRONIZER_URI)
and if you have multiple forms in the same page, define a variable to hold tokens returned from each ajax request.
btw, why not implement the token pattern on your own?
Generate a token, e.g., UUID.randomUUID().toString(), and store it into session with the url as the key.
Check and reset the token at the satrt of post actions.
I am applying Security to my .net 3.5 mvc2 web application.
My website doesn't contain any user authentication and consists of many ajax calls in .js files
In my .aspx file I wrote
<%= Html.AntiForgeryToken() %>
In my .js file function I wrote
$(document).ready(function() {
var token = $('input[name=__RequestVerificationToken]').val();
$.ajax({
url: "/Home/getCurrentLanguage/" + Math.random(),
cache: false,
type: "POST",
async: false,
data: {"__RequestVerificationToken":token},
success: function(data) {
if (data == "mr") {
alert("its Marathi");
} else {
alert("its English huh !!!");
}
return false;
},
error: function(data) {
alert("some Error" + data);
}
});
});
In my Controller I wrote
[AcceptVerbs(HttpVerbs.Post), ValidateAntiForgeryToken]
public JsonResult getCurrentLanguage(string id)
{
return new JsonResult
{
Data = "mr"
};
}
This works fine for me,
but I have 2 Questions
Q1. Is it the correct approach ?
If I see the page source, I found this code
<input name="__RequestVerificationToken" type="hidden" value="WFd+q5Mz0K4RHP7zrz+gsloXpr8ju8taxPJmrLO7kbPVYST9zzJZenNHBZqgamPE1KESEj5R0PbNA2c64o83Ao8w8z5JzwCo3zJKOKEQQHg8qSzClLdbkSIkAbfCF5R6BnT8gA==" />
but when I created the external html file and copy this value of __RequestVerificationToken and pass in ajax call, I am getting this error
A required anti-forgery token was not supplied or was invalid.
then
Q2. How does runtime know that this page is supplying the copied __RequestVerificationToken?
This "AntiForgeryToken" is in place to prevent Cross-Site Request Forgery attacks. This system can be undermined by an attacker if your application suffers from a Cross-Site Scripting vulnerability.
This token prevents CSRF attacks because due to the same-origin policy the attacker can send requests but he cannot read the token off of the page to make the request succeed (unless he has an xss vulnerability).
As for Q2, this value must be unique per user and therefore updated each time the page loads. If its just a static value, then its useless at stopping CSRF because the attacker will know this same static value.