I've bumped into several users that have cookies disabled and therefore the site doesn't work like I'd want. I'm using webapp2 and django 1.2 templates with {% url %} template tags on appengine.
I'd like to find an easy way to address this that doesn't make me end up making LOTS of code changes. Going to all my urls and conditionally adding ?cookie= to all of them is going to be a real pain, so I'm hoping there is a simple solution to this problem.
It causes problems with the CSRF code on forms too, what do you do in that case, just give up CSRF?
I can do some stuff in the urlNode code since I should be able to resolve the logged_in_user object from the context, so that might deal with a good bit of the problem, except any place that adds params after the ? will now have to use &. All in all, NOT a pretty solution.
Anyone know of an easier way to deal with this?
I don't recommended building site with cookies as optional requirement, site design gets soon extremely complicated and you probably open more security holes that you can imagine. If you must support users without cookies, use HTTP basic authentication to authenticate and recognize users.
Related
I have a frontend developed using Next.js in which I consumed Storyblok API to get dynamic content.
I want to use it as a Block in Theme App Extension instead of refactoring the code into liquid
Is that possible?
I really appreciate any help you can provide
Ps:
If there is a better way to do that let me know
I tried adding it as IFrame but it is not recommended for SEO and performance
Go for it. You can do whatever you want in a block. You control the HTML(Liquid), JS, and CSS.
Note that you are probably killing a fly with a sledgehammer but that is your burden to bear. If your block is somehow slow or in-efficient, it'll show, but maybe it'll be zippy and great. Just throw down the code and see what happens. Should not take you more than a few minutes to establish whether you like it or not.
For normal functions, I think it is okay to incorporate all pages in to one react app using routes.
But when it comes to admin page, I think it is wise to create a separate react app which will compile into a different .js bundle and serve this not though react route but a totally different html along with the separately created js bundle.
I think if we bundle admin and normal functions into one file and serve through react router, there is a risk where the client can look into the js file and decipher admin pages. Couldn't this be a security risk?
If I'm overthinking please let me know. Other feedbacks are also welcome
Assuming that whatever backend is serving your React application has properly-implemented authentication, it's not technically a security flaw; a malicious actor can't negatively affect your product purely based on the admin page source being bundled with everything else.
That said, it does make it easier to see how your admin tools work, and gives someone nefarious a good indication of where they need to look for exploits.
Personally I'd never serve up a consumer-facing application and admin-facing application in the same codebase. Even though it's not exploitable directly, it makes it easier to find a potential exploit. Security through obscurity is largely a fallacy, but it never hurts.
You can use lazy loading, not to send whole pages in one bundle. but if they are totally different with no functional overlap, it's better to separate them, better responsibility separation, cleaner git history, etc ... And unless you are not exposing valuable data like hard coding api key, reading js source isn't a problem. The security breach happens in the back- servers and the back end services should be using some sort of authentication to respond, check OAuth, OpenID workflow. Its a very common pattern and used by tech giants.
We're using wagtail with CSP (obviously) which means that every time we need to transclude/embed some content from another site we need to update a CSP whitelist as the only way to ensure that server headers play nice with embedded content.
Is there, however, a way to do this from within Wagtail itself, through its admin UI? This seems like the kind of thing a CMS-ORM should be pretty good at.
Looks like this isn't a feature of WagTail at the moment. It looks like there is an open ticket on CSP issues (especially regarding Django CSP integration). It might be a good idea to add your complaint about the lack of UI to that ticket.
Since Wagtail is built on Django, I would suggest using the Django CSP library in the meantime, it seems fairly straightforward and is backed by Mozilla.
We have a website that's running AngularJS 1.*
but one of our main clients are military personnel and they frequently attempt to use the site via Department of Defense computers. These, of course, have javascript disabled.
I've heard of doing server side rendering, but the majority of the examples and research just mention using it for the initial load. We would need the entire site to run off that principle. Essentially acting like an old MVC site. Is this even possible? And I don't mean with just angularJS. Angular 2(5, whatever version we're on now), or react. I just really don't want to back track to .net MVC
Edit: I realize this is, for all intents, a silly question. I was just hoping there was some awesome new tech that had solved the issues that would be present in even attempting this (as stated below, data-binding. I realize this concept completely defeats the purpose of SPAs)
Thanks anyways. I may just delete this question. Didn't have too many expectations to begin with.
This is very possible! Don't let the rest of the people here fool you.
We have a few websites that work just fine with or without JavaScript enabled. My company website https://bitgenics.io is a React app. If you disable your JavaScript the only thing that won't work is the client-side video player.
Now I have no experience with Angular 1 (and I have heard SSR is hard there), but support should be better in the later versions of it.
Getting the GETs to work is the first challenge. But the next one is that you have to have a fallback for your HTTP POSTs. SPAs often use straight REST calls to do any state changes, but you can't do that because it requires JS on the client.
So your forms have to a fallback of a regular FORM post. So you might need some server-side logic to receive these POSTs and respond with a Server-Side Rendered page again.
I have a function in the back-end that relies on the property names of an object, which is sent using AJAX with AngularJS. Can a user alter the property names using a debug tool, therefore changing what I would normally expect in the back-end? I suppose doing that would also affect the entire app in general if it was possible.
I guess it's kind of like someone using a debug tool to change the name attribute on a form and then submitting it. So I was curious to know if it's something I should ever keep in mind for AngularJS. I hope that makes sense.
If user is smart enough, he or she can change mostly everything using developer tools browser brings. What is more, if back-end endpoint is known, it easy to mock custom request with custom data.
You should always validate request since everything what doesn't come directly from your code can lead to security break.
The big downside of Ajax is that its requests are easily debugged using dev tools and, if are not designed correctly, expose your internal structures.