Hi, I am using form based Authentication in my Application. I want to know is there any way i can pass the username and password in the url so that the user need not enter it when accessing a secured resource.
Its somethink like i have 2 different applications App1 and App2 , and i am calling a secured page from App1 in App2 now as the page is secured the contaner will prompt for username and password , therefore while calling the page itself i want to give the usernme and password so that the login is carried out and secured page is seen.
While browsing i found somethink like this..... but what is g2_form i didnt get .... and also i dont no what is UserLogin,Login
posted 10 years ago
Looks like a random URL to me - what's it have to do with your problem? Obviously you *can* pass in the URL whatever you choose, but that doesn't make it a good idea. FORM authentication works with POST, not GET, though - so anything you do in the URL will have no effect.
Let me make a distinction between "Form-based Authentication" and "Container Managed Security".
Form-based authentication is simply any system where a form is used instead of (for example) a popup dialog to collect login credentials. An application can design its own forms and its own logic to handle login and that will technically be form-based authentication. Of course, if it's like over 95% of the webapps I've seen with DIY security, it won't stand a chance against a halfway determined 10-year old. but that's another matter.
Container Managed security means literally what its name says. Container Managed Security. You don't present a login form when doing form-based Container Managed Security. The container does. It does this when it determines that the user needs to be authenticated, and it does thus by pushing the incoming URL request off to the side, running an internal login process, then resuming the original URL request (assuming the user logged in).
The Container Managed Login Form has no external URL.
The "j_security_check" URL is a postback URL. It cannot be directly invoked, it only functions when the container has posted out a login form. The container has constructed a login context before the form is presented. That context does not exist when a stand-alone URL request to j_security_check is made. That's why any attempt to explicitly login using container-managed form-based security will fail.
You can induce a container-based login by causing the user to invoke a protected URL. You cannot induce a container-based login directly. The converse, however, is also true. You cannot bypass a login on a protected URL. Which is one of my favourite ways to outwit the DIY security systems.
"privilege" comes from the Latin words for "private" and "law" (legal) and dates to feudal times. To "claim privilege" meant that you were above the laws that applied to the common people.
please buy this thing and then I get a fat cut of the action:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop