I have created a login app that is responsible for the login of other five applications. So when the user correctly authenticates in the first login, he can access all the other apps.
I have achieved this using the same cookie name for the login app and all the other applications.
But only one of this applications must be accessible from the outside
too, and not only from the login page. So it must have his own login page.
Question:
Is there a way to make this application accessible in two ways?
One way coming from the login application and the other way from its own login page?
Or I must have two separate applications?
Thanks.
So, this "login app" is used as a menu which enables users to access 5 different applications. Those are, I suppose, Apex applications.
If that's so, make the link (i.e. URL) to the one that has to be accessible "outside" of the login app available to users separately. All of URLs are the same, aren't they? You only change the APP_ID value.
Now, the problem might arise with the way of authentication. How did you do that? If it is user-defined, and "available" only in the login app, then you'll have to make it available to that separate application as well. Otherwise, users won't be able to connect to it. Lucky for you, you can create a new authentication scheme as a copy of existing one.
Though, underlying database objects (such as table that stores usernames and passwords, functions and procedures used to create new users and fetch data about existing ones, password validations etc.) will also have to be accessible to another database user. That can be done by granting appropriate privileges (SELECT, INSERT, UPDATE, DELETE on table(s), EXECUTE on stored procedures).
Therefore, no - I don't think that you should maintain two exactly the same copies of that application to make it work.
I am building a web app where different companies will upload their own audio files with some additional information. I am building it using Django, Postgres and hosting it on AWS. Users belong to different companies will only be able to access their data when they log into the website.
The website allows those users to upload content, search content and access content.
My question is, what's the best practice to handle those uploaded content? Is it better to create different schema for each company or putting all the content together and allow users to access different content based on the company id that each entry associates with?
putting all the content together and allow users to access different content based on the company id that each entry associates with?
Personally, I would do this, for several reasons:
It's easier to maintain. Adding new companies probably just means a new ID, rather than a new schema and some tables.
You can add security with application code or with database views.
You can have other company specific functionality that uses the same design.
I would also suggest enforcing the data security on the database side, by only allowing the application to query from certain views, where the views are limited by company ID. This means that you won't accidentally SELECT from a base table and forget the company filter, causing the user to see data that isn't theirs.
This is just my opinion - happy to be proven otherwise.
I'm newbie on apex, and made an application that demands the app admin to insert users - in customized groups, on apex workspace - Manage Users and Groups. My application uses Authorization Schemes based on these customised groups, instead of create an Access Control List. I guess this is more useful, because It's could be possible to make more and different groups, and more flexible access control of pages, reports, buttons etc. But this kind of implementation could bring some security issues on my office. I wonder if is possible to create a page that refers, and also mantains (CRUD) to this workspace users, at workspace groups?
I'm currently working on designing a REST-style SQL-backed web application that is to support multiple types of user roles. I'm looking for ideas for implementing an authorization abstraction for it that's both simple and powerful.
The hierarchical roles in the system would be along the lines of:
superuser/admin -> group owner -> group user
A real world example of this system would be: "I'm a school administrator, I have teachers I manage, and they all have classes that contain students".
I'm thinking along the lines of a UNIX model, except one admin's data silo cannot overlap with another admin's. In the example above, one school should never have access to the data of another one.
An admin role would have full superuser powers over every group and user under him.
A group owner would only have access to the group itself and the users under it.
There can be multiple admins for one silo of data, multiple group owners per group etc.
Admins / group owners / users will generally not change what they can do, as in they abilities will pretty much fixed. The thing that will change is what pieces of data they can act upon.
I'm absolutely certain there have to be a few general patterns out there that I can start with and develop a custom authorization system around it that's fine-tuned to my system's needs. There's ACL, there are libraries along the lines of Rails' CanCan and I'm sure many more.
I'd love to know what my options are and what some of the trade-offs would be. Resources, readings, articles, books would be all great. It's likely I'll have to implement a Parse.com-like API for this web application (i.e. API clients can write custom queries as JSON maps and those will be translated to SQL on the backend) and it'll be extremely important to prevent unauthorized access in all sorts of different query variations.
Thank you.
P.S. Just to clarify, I'm not actually on Rails, the stack I'm using has no existing libraries for authorization, hence I need to roll my own.
I would check out the hartl tutorial to implement users and admins and user levels
http://ruby.railstutorial.org/chapters/modeling-users
This is something of a rant, as well as a question.
There are some sites, like Facebook, where you would only want to be logged into one account at a time.
But everything from blogging sites to email always force you to logout before you can login to another account.
And I understand the security implications, and how it would make cookie-based sessions a little more complex, but why don't we see more of this?
Why would multiple users from a single client at once be a bad idea?
I think this is something that should be implemented by browsers by allowing multiple sessions, each using their own cookie/authentication/etc.
That would probably be the best solution, as it would seem to work for all sites, and require no updating for them, and, although I don't know much about it, it doesn't seem it would be terribly difficult to implement either.
The simple problem is most sessions are implemented via cookies, and there's pretty much no way to do it without cookies.
And the way cookies work, is they're bound to the domain/path, and all cookies tied to that domain are sent.
So if you permit logging in twice via 2 different cookies, the problem would be every successive page would send BOTH cookies, and the server seeing both has no idea which "user" you are acting as.
The only way around this is passing a "thread" identity around all links, ( that is, rewriting every site link on the fly to foo.bar?thread=2 or thread=1 to indicate which session to use for things ), and that is a complete nightmare, not to mention security implications.
The only real way to do it is via browser-sand boxing, the user tells the browser that a given tab and all offshoots use one cookie set, and the other tab and all offshoots use another.
In essence, its not a problem that can be solved by websites in a practical manner.
There's practically no good way to store this information without delegating the controls to how it works to browsers to implement, and for users to manually indicate when they want to fork into a new session.
Single Browser Solutions that should work today:
CookieSwap 0.5.1 Appears to permit "state toggles" of various cookie sets, It doesn't do whats needed to be able to just browse them magically, but its a partial solution. I can't test it myself because it hasn't been ported to FF3.1 yet.
"Why would multiple users from a single client at once be a bad idea?"
It is not a bad idea at all, but the use of HTTP forces us down this route.
Most client/server protocols are stateful - the client need authenticate only once during handshaking and then the session is represented by the socket connection. If you lose the connection, you lose the session and have to re authenticate. It is then trivial to write applications that allow multiple sessions (as the same or different users) in the one process.
HTTP is stateless. The client needs to re-authenticate in some manner with every single request. Authentication information is usually stored in cookies so that the user does not have to be involved once the initial authentication has been done. Cookies, however, are global - not just global with in the process, but generally across instances/invocations of the application. Hence, you are stuck with a single session.
You would have thought that web-app designers would have looked at this massive limitation as a sign that HTTP just isn't the right protocol for client/server application development.
One implication of multiple logins is how to manage privileges. Say I have two accounts, one has a privilege to delete user accounts and my other account lacks this privilege.
If I can be logged into both of my accounts simultaneously, which takes precedence, do I have the union of privileges from both accounts, or only the intersection of privileges held by both accounts?
If I have the union of privileges, would I have the ability to combine privileges from these multiple accounts in ways that give me too much power? What does this imply for Sarbanes-Oxley compliance?
An equivalent issue is seen in SQL, with respect to "roles" which are groups of privileges. In standard SQL, a given account is permitted to adopt multiple roles, but only one at a time. This prevents you from exercising too much privilege.
Cookie state is anchored to the host header...
Use a different hostname or use its IP address directly to connect to the site. Depending on the site you may be able to setup a bunch of local host aliases to the site allowing you to be logged on more than once as each alias would have its own cookie state.
If the site redirects to itself to force a specific host header the aliasing won't work and you'll need to use multiple browsers.
Since you first wrote the question, IE 8 has been officially released and it has a built-in feature that does what you want. From the "File" menu, click on "New Session." This will open a new window that will not share session cookies with the original window, allowing you to be logged into the same site under different logins simultaneously.
http://blogs.msdn.com/ie/archive/2009/05/06/session-cookies-sessionstorage-and-ie8.aspx
You can do multiple sessions in Firefox by creating new profiles - run: firefox.exe -P which is where you can set up multiple profiles that will have different cookies - you can run multiple sessions of firefox at the same time by using firefox.exe -P "profileName" -no-remote . the no remote will only allow 1 window per session but will also allow multiple sessions at the same time.