In my codeigniter application following is the format of user profile
http://example.com/foo/view_profile/userid
how can I restrict a user to view others profile? that means he cannot browse any other link than his profile.
so user foobar420 can not browse following links for example
http://example.com/foo/view_profile/foobar250
http://example.com/foo/view_profile/
http://example.com/any-this-else
How can I achieve this?
Was going to comment this, but it's sort of an answer. Well an idea on this subject at least.
Instead of having "/view-profile/userId" why not just "/view-profile" and send the user model as an object to the page. Then you can just render the proper information only for the user who is actually logged in to the server. Assuming you have access to the user model in your server side script, this is the preferred method.
And if no user model is present, redirect to the login page.
Related
I'm trying to figure out how quickest and easiest to allow the admin user on the site I'm building to access and update any user's settings etc. E.g. I've written the code for a regular user to update their settings (and various other actions). Ideally I want an admin to be able to "be" that user as far as my code is concerned, i.e. allow the admin to do anything a user can, to that user's account. Is there any way of doing this?
If I Auth::login() as admin then from the point of view of Laravel I'm the admin user and not the user they might want to edit. If I login as the user then I don't have admin rights (which in my case means an extra admin menu on the navbar with options to suspend or delete the user, or search for other users).
Any thoughts on how to do this please, or am I overcomplicating things? I am looking for a specific functions/code to allow this, rather than a general strategy. I'm using Laravel 5.4, deployed on Heroku. I know there's middleware but it doesn't seem to do what I want as above.
Many thanks.
You could do as suggested in the above comment by Tim Lewis, or you could accept an "override" property in the user edit page where you can pass a specific user ID and then view the page as that user. For instance, the method might look like this:
public function editUser(User $user=null) {
//User that you want to edit can be provided. If not provided, $user will be null and we will load the user that is currently logged in.
if($user!=null && Auth::user()->role=='admin')
$user_to_edit = $user;
else
$user_to_edit = Auth::user();
//other code goes here
}
Then, if you pass a $user object to the method, you will be given the edit page for that user, rather than the Admin. Otherwise, a user will be able to use the same route in order to always view their own edit page.
Be very careful with code like this! You will want to make sure that non-admins do not have the ability to load in a user object and see somebody else's information. That's why I added the $user->role check in the if/else statement, but you might want to add extra security in the form of middleware.
spatie permissions is a wonderful package that I use to make permissions to resources available to super-administrators. https://github.com/spatie/laravel-permission
I have a little problem about this scenario.
I have 300 users in my system. each user must have user panel. it is one page that each user after sign in to the system and went to own page,can edit his content and customize it.
my question is : how to define permission for each user in order to access to own page and don't access to other's personal page.
thank you.
You just need [AbpAuthorize] attribute for the related application service to prevent unauthorized users to see that personal page. And when the user opens the page load the data with the current user's information as #aaron stated in the comments.
I got a multi-step form where a user select a phone model, brand, etc and when they click get quote they get a price based on their selection.
To be able to confirm the quote, they need to put their address details or if they already have an account they can login.
The question is how can I redirect the user after they login to a different view with the quote details?
Thanks
By default after users login they get redirected to /home. If you want to change this functionality just define a redirect path in your AuthController like this:
protected $redirectPath = '/your-show-quote-page';
Check Authentication in Laravel Docs for more information
Based on your question, one way of doing what you want is:
Create a quotes table and store the quote information with your multi-step form,
Ask the user to login,
Redirect the user and show him the quote based on his selections.
Lastly, depending if the user is interested in buying the phone you can redirect him to one place or another and delete the quote when you don´t need it anymore.
Other way would be to store the information about the quote in the session and display it when needed. For this you can check Session in Laravel Docs. The process would be the same.
Hope it helps.
I'm assisting another developer with adding a link to a page in a product called Lawson that we use in-house. I need to pass the authenticated user's employee ID to an HTML page we're bolting on. I'm still looking at existing pages on the server, but thought I'd ask: does anyone know how the Javascript object that represents the authenticated user works? It looks like something server-side must be dynamically creating a Javascript object that has useful properties. It is usually called 'AuthUser'. I want to add the necessary JS references to my new page to support this object and access its properties. Does anyone have any experience with that? Thanks!
If you are in a portal session, you can access this in javascript through attributes of portalWnd.oUserProfile:
alert(portalWnd.oUserProfile.getAttribute("id"))
This will give you the logged in user's short username. Many other attributes are available. To see a complete list, log into a portal session and then replace the URL with:
http://YOURPORTALSERVER/servlet/Profile
I'm not sure what you mean by "bolting on", but if you want to pass an attribute to an external page launched from a Portal session, you could create a user shortcut via Portal preferences using something like:
javascript:window.open("http://yourserver/yourpage.html?user=" + portalWnd.oUserProfile.getAttribute("id"))
as the target and process in yourpage.html like a normal GET method form.
If you are still puzzling over this all these months later, provide some specifics if you need more guidance.
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.