Mircea Carasel wrote: > Well, I don't know if here is more related with browser cache than > with Acegi security cache. I believe that when a rest service is > called from a browser (through Ajax capabilities) the browser may > cache or not user credentials. In case of XX-7641 I think that the > problem was more related with the fact that the browser continuously > asked for user login when a REST service call attempt was done > (ignoring cache). >
Ah, yes. You are right. I forgot to account for the differences in the authentication schemes. When you normally log into sipXconfig, we set a session id cookie, which is cached by the browser, and is invalidated when you logout, or restart the JVM. When you call a REST service from within this session, the browser makes use of this session id to authenticate the service. However, after you logout, your session id is invalidated and we get an authentication pop-up the next time the browser makes the REST call. Here is where your browser falls back to the basic authentication scheme, and caches the actual username and password. Once authenticated, the browser will send the credentials to the server with every subsequent HTTP request. And this leads to trouble when you log into sipXconfig again, under a different user name. Now your session id is associated with User X, and your browser cached credentials are for User Y. Which inherently led to the behavior where we could acce ss the superadmin portal from the user portal. Arjun _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
