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.
Related
I have a website that authenticates users with the active directory. This website is made for internal company use and does not hold any sensitive information. The website is secured with SSL. When a user logs in, his/her username and password will be transmitted to the server through POST. I then store his/her username in a session cookie with a TTL of 1 day, refreshed by every single web action. From this point on, every webpage will check to see if this cookie with the username exists. If it does, it will allow users to access that certain page. Login out will just remove this cookie.
Would this way of authentication be acceptable? Is there a better way to handle user authentication? Is it necessary to use sessions instead and store session id's in cookies?
It does work out nicely to use Sessions, yes. I don't know what language you'd be using, but storing information in general locally is a good idea (this does not include sensitive and private information, ie. passwords).
Pages usually check your authentication (and its type) upon loading.
I've lost my touch with PHP, but for instance ASP.NET has a pretty neat (but complicated) Identity system where your login information would be stored in a separate Session, and destroyed upon logging off, but also stores information regarding its Type. This would later allow the developer to mark pages that would require a specific type of an Identity. For example:
[Authorize(Roles="admin")]
public ActionResult Index() {
// Your action information
}
Again, I'm rusty with PHP, but I imagine it's similar where you'd simply check the Sessions before the <html> tag, ie.
<?php
if(is_null($_SESSION["user-info"]["type"])
header("Location: index.php");
?>
<html>
...
Overall, the way you use sessions in each of the back-end web development languages could defer, but the overall usability is the same. You'd use Sessions to store User information, Store "basket" items, etc.
How can I implement this behavior in my website
I need to be logged inside my website to navigate through the website and if I open a new tab, I want to display the login page, also the user logged on the previous tab doesn't have to be logged on the new one.(treat all new tabs like independent session)
when the user is logged a security token is stored on my Session[token], if I open another tab, another user can be logged into the website with another token session.(this has to be don't in the same browser)
There are many ways to do that but each has some limitation. All ways required some short of custom development on client side and server side to manage the data.
Don't use cookie or traditional authentication mechanism as all has cookie per domain so it wan't help.
If you are using HTML5 then you can take advantage of sessionStorage and store different Id ( generate guid) and pass along with each request to identify. ( More secure you have to generate your own encrypted value)
For simple use you can use HiddenField on each tab and get value from Url.
If you are aware of ASP.net cookieless session then you can see that url has sessionid and you have to do something similar.
In MVC you can do such thing by creating custom route.
http://blog.gauffin.org/2012/02/get-a-unique-session-in-each-browser-tab/
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.
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 making a bookmarklet, which calls a Google App Engine app. The GAE app uses login information, which I want to store in bookmarklet, so when user first clicks bookmarklet,it asks for login info, but from next time onwards it automatically supplies it.
The difficulty of a bookmarklet directly storing data is that it can only store data in cookie or in localStore, both of which "belong" to whatever page it is currently on. That means it won't work again the next time you use it on a different page, and it also means the page you are on can access the data, which is generally very bad for security.
There are two basic ways your situation is generally handled. The two main ways are:
1.) The application used keeps the user logged in with a cookie. The login information is not stored in the cookie; only a session ID is. This is like when you return to many popular websites, you don't have to log in again. Very often these types of bookmarklets open a small popup for the user which contains a page from the app. If the user is not logged in, the app prompts the user to login first. The bookmarklet in fact knows nothing about being signed in or not.
2.) Each bookmarklet is custom created for each person. So my bookmarklet would be different than yours. The difference is simply that mine will contain my login info in the code, and yours will contain your login information in the code. In fact we would each have to login to the app first before we can get our own personalized bookmarklet.
Generally, option 1 is better and easier and more secure.
If I understand it correctly,this Might help you. http://ajaxian.com/archives/whats-in-a-windowname
It allows for storing data in windowname in JS. Allowing for access of up-to 2 MB of data (A lot more than cookies can hold) and I believe can be used across tabs...