I'm using laravel/ui for authentication, let's say i opened my website in two separate tabs.
After i logout from one tab, if i click let's say delete blog button on other tab,
it takes me to login page as i'm using auth middleware, after which if i login and my delete action runs.
How to prevent this, i only want delete action to run when user is logged in and in the above case, after user logs in, i don't want to perform delete action straight away, user needs to click delete button again.
There are several solutions:
The best practice would be to change the delete request type to POST. Check here how to correctly use HTTP methods
In your Auth middleware, always redirect the user to some landing page.
I would strongly advise changing the request type. Once, I had to help to restore an IT system where some smart arse ran script to follow all links in an internal website and fetch all pages. Delete operations were implemented with the GET method.
Related
I have a website, running on Laravel 8 and Vue.js 3. Admin panel's front-end is completely on Vue, while guest users are served with Laravel's blade.
I have worries about unauthorized client's possibility to inspect admin panel's code on login page, as it's part of Vue.
Of course, client will not get any information from server, without authentication. All she/he can see is blank panel with no information at all.
So the problem is, client can analyze a whole functionality of code, view all routes that is used to manage site content. This gives full information to security researchers where to target, what to send and what to expect.
Also, I know about Asynchronous Components, but this is not answer here, as those component's are named by predictable names. So it's possible to get whole working code anyway.
If I will make subdomain separately, those subdomains can be also scanned and exposed. As managers are working from separate locations, denying of route, based on IP address is also not solution.
How to control this from Laravel, so only authenticated users can see panel's code? Should I try to fix this at all?
The way I do is by compiling two differents files using webpack and a logical test whitin the blade file.
So, depending on the user type, the page will load differents files, but I do not mind them staying in the public directory. I put every administrator request inside an administrator middleware.
You can make laravel moving files from public directory and an another one using some sort of control. Exposing your admin files only when an administrator request a page and until the load is done. I know this is possible, I never tested it myself.
I'm currently implementing this library ember-simple-auth to manage authentication in the emberjs application (shopping cart) that I am currently building.
The difficulty that I encounter is that the library manages authentication rules after logging in very well but not before logging in.
So here is the scenario:
The application must talk to the backend server to retrieve a session token for every user. This is necessary so that the user can save their items temporarily in the server side using session data. Something that you would expect for a shopping cart.
Then when the user is ready to move forward the application will then display the login screen and the user can authenticate themselves to checkout their items.
However, I can't seems to figure out yet how to do this using simple-auth. If I create a custom authenticator that just fetches token id from the server, it will mark the session as authenticated and will not ask for login on the authenticatedRoute.
In general what I'm trying to do are:
Customer visit the website
The application fetches session token from the server
Customer clicks around and saves item into the shopping cart. The data is synced with the server using the session token
Customer ready to checkout and navigates to checkout page
The application intercepts the route and redirect the customer to login route, where the customer can login and resume checkout.
I hope the above information is clear enough. Any hints and help will be much appreciated. Thanks.
I would probably only use Ember Simple Auth from the point on where the user actually logs in. Before that instead of using a session token to identify the basket, I'd probably explicitly create a basket on the server side (POST /basket) and then add to that via a REST interface (PUT /baskets/:id/items or so). That way you're not sharing state between the client and the server and have a clear interface. You also don't need to "abuse" Ember Simple Auth which probably only leads to other problems later on. When the user logs in then, you simply assign the previously created basket to that user and go on.
I'm working on a shopping cart and facing an issue with FOSuserBundle registration flow :
My users can add whatever they want to their cart, being or not logged/registered, but before checking out, i want them to login/register.
The main important thing is that I want after login/registration they can get back the same shopping cart they had before. To achieve it, i'm saving into the user session a random key and i'm saving this random key in the database with all articles data.
I hava no problem with the login flow, the session is kept without any change (symfony preserves all session data), so the user retrieves his session, but my problem is with registration.
When the user wants to checkout and have not an account yet, he needs to register, and when the registration is complete (with FosuserBundle, sending an activation link by mail) the user session is completely resetted so the shopping cart is lost but has not really disappeared : Actually, a weird thing i observed is that the browser seems to deal with 2 different sessions at the same time but in 2 separate tabs, in the old browser tab (before registration), data is still here, but in the new tab the session is cleared
So my question is, is there a way to give back a user his session after a successful registration in Symfony2.1 and while using FosUserBundle?
Thank you in advance
My security config file was the cause
I had to set the option session_fixation_strategy to "migrate", that now works perfectly, thanks
Login/Logout is handled by symfony's 2 security component while registration is handled by FosUserBundle.
You can try to override the registration handler https://github.com/FriendsOfSymfony/FOSUserBundle/blob/master/Resources/doc/overriding_controllers.md and migrate your old session: http://symfony.com/doc/current/components/http_foundation/sessions.html#session-api
The situation is quite complicated and why do I need it - do not ask - boss want!
So, immediately after the default authorization i need to run the custom module, which will have an additional test for authorization in another database and depending on its result i need to decide authorize user or not.
Are there any suggestions except for source corrections?
If you are using Joomla's built-in 'Login Menu', you can set 'Login Redirect' parameter to another page and if you are using Joomla's native login module, you can set redirect parameter to any page of your site that you want.
In your case I would recommend to create a simple component (not a module) that authorizes your user for second time, and redirects them again to any other page that you want (if second login was successful) or kick the user (if second login was unsuccessful). If you do that, you'll be able to create a menu for your component and redirect your login panel (either it's a menu or a simple login module) to your component's menu.
Creating components for Joomla is not a big deal if you have a little of knowledge in php programming and there are some tools that may speed up creating your component, like this one: http://www.notwebdesign.com/joomla-component-creator/
Why not make an authentication plugin and use that rather than the core joomla one?
This is for 1.5 but the principles are the same now.
http://docs.joomla.org/Creating_an_Authentication_Plugin_for_Joomla_1.5
Are the Joomla login credentials for a user the same as the other system that you are using? If so, then you can create a plugin that passes those credentials to your other system on a successful Joomla login event.
If not, then it gets a little tricky. Either your users will have to provide both sets of credentials, once for Joomla that then redirects to your other system for the second login, or you will have to extend your user accounts so you can associate the second set of credentials to a user. You can then use a plugin to pass the related credentials to your secondary system after a successful Joomla login event.
I am wanting to build an admin tool where I can "impersonate" users of my site, without having to lose my session as an admin.
I would like to be able to open an iframe that will view the website "as the user", without changing the state of the page that opened the iframe.
Is that possible? Is there a better way to do this?
It's possible, but there's a bit "but" :)
Just a couple options to start with:
Use URL-based session tokens (as Java Servlets do when you have cookies disabled)
Use different domains for "normal" site and admin interface
iframe itself won't help you much: it will always share its cookies with the browser. So in order to avoid that, you can use either of the above options—but that does not depend on the iframe.
What language? My answer is based on the assumption that PHP is your chosen language.
Firstly, I would say you have planned your application wrong if session impersonation is the only way you can view your site as another user while still keeping your admin login intact.
One way you could do it, and again this is assuming that you are using PHP as well as the default session management functions within and you do not have a custom session handler would be to load the iframe url with the ?PHPSESSID=sessionidhere parameter.
A better way to do this is to create your site and authenticate users via a user object of sorts and then add some sort of url parameter such as ?userbrowseid=123
Then when you load the page, your code will only check if the parameter exists if you are already logged in as an admin. The page would then overwrite your current user object with the user object of the user with the id 123. Steps should be taken to make sure your session cookies are not overwridden with the impersonated user object. As this would be in an iframe, your site will work as an admin and the iframe will be loaded as the user object.