Skip to main content

Re: Diff for 18235

  • From: Jason Lee <jason.d.lee@...>
  • To: dev@...
  • Cc: Amy Roh <amy.roh@...>, Tom Mueller <Tom.Mueller@...>, Shing Wai Chan <shing.wai.chan@...>, Loren Konkus <loren.konkus@...>, Michael Chen <michael.y.chen@...>
  • Subject: Re: Diff for 18235
  • Date: Fri, 26 Apr 2013 11:59:40 -0500

Shing Wai? Amy? Any thoughts on this?

On 04/25/2013 04:20 PM, Jason Lee wrote:
On 04/25/2013 03:50 PM, Amy Roh wrote:
On 4/25/13 12:00 PM, Jason Lee wrote:
As best as I can tell, it's returning the correct VS. I think everything is working as expected except the console, as I noted, but I can't figure out why not.  I need some input from the web container group. The system-application is installed, but, for some reason, the system still hands the request to the AdminConsoleAdapter, rather than the web container. I'm guessing that's happening somewhere in ContainerMapper, but I haven't been able to ascertain where or why.

Don't we want to keep the same behavior of handing over admin requests to the AdminConsoleAdapter but modify the AdminConsoleAdapter so that it allows access based on the --hosts value of "__asadmin" virtual server?  Can you explain why we want web container to handle admin requests now to fix 18235?
As I understand things, once the Console app is installed and loaded, the AdminConsoleAdapter is never accessed again until the server is restarted. Once the app is up and running, the web container handles those requests. That being the case, we can't put these restrictions in this Adapter, as they will be bypassed once the app is running. I tried that approach, and it doesn't work.

The changes in V3Mapper seem to undo the fix for https://java.net/jira/browse/GLASSFISH-5664.  IMO, we should continue to not register any admin related artifacts on a non-admin listener as this will cause issues.  In general, web container handles "__asadmin" virtual server and "admin-listener" network-listener differently from standard virtual servers/network listener/web module. 
For the time being, since we're changing the name of the "virtual server" we're storing, I've disabled those checks to make things simpler.  Once (and if) we get the overall change working as requested by the user, I'll reenable and clean up those checks to handle things appropriately for the final state of the change. For now, it's just easier to disable those and worry about them down the line a bit.

Amy

I've attached the current state of the change. I'll keep poking, but I could use another set of eyes.

On 04/24/2013 10:04 AM, Tom Mueller wrote:
Great work Jason and Ryan.

On 4/24/13 9:52 AM, Jason Lee wrote:
Here's the current status and diff for this issue. With the attached diff, asadmin and REST traffic are restricted as expected.  For this configuration (with localhost, test1, and test2 all resolving to 127.0.0.1):

<virtual-server id="__asadmin" hosts="localhost, test1" network-listeners="admin-listener"></virtual-server>

host/operation
REST
Console
asadmin
localhost
Expected response
200 with empty body
Expected response
test1
Expected response 200 with empty body
Expected response
test2
404
404
404/Command failed

There seems, then, to be more work done on the web-glue side to make this correct.
When you say "200 with empty body" for the Console, does that mean that console access is still not working? i.e., is there a missing "to be" in the sentence above?

Regarding the diffs, please take a look at
+        VirtualServer vs = locator.getService(VirtualServer.class, dvs);

There could be multiple virtual servers with a given name in different configs. In fact there are 2 by default with the name __asadmin, one in server-config and one in domain-config. So this line might not fetch the right VirtualServer.

Thanks.
Tom


One final point: with the current state of this diff, if the virtual-server configuration is left with its defaults, nothing seems to work. I'll try to figure that out once the issues above are ironed out.

Many thanks, by the way, to Ryan Lubke for his help on this issue.


On 04/19/2013 10:40 AM, Jason Lee wrote:
Per Shreedar's request, attached is the diff of my current attempt to
address http://java.net/jira/browse/GLASSFISH-18235

The changes in addHost() and addContent() is a less than elegant attempt
to work around the sanity checks mentioned in the source comments.
Ideally, we'd probably pass the VS in, but these methods override those
in the Grizzly base class, so it's not that simple, it seems, but
something that can be addressed once we make it work.

At any rate, the net effect of this change so far is that all traffic to
port 4848 (Console, REST, and Asadmin) returns a 404, for reasons I've
not yet been able to determine.  If anyone has any tips, I'm all ears. :)



-- 
Jason Lee
Principal Member of Technical Staff
GlassFish Team

Oracle Corporation
Phone +1 405-216-3193
Blog http://blogs.steeplesoft.com 



-- 
Jason Lee
Principal Member of Technical Staff
GlassFish Team

Oracle Corporation
Phone +1 405-216-3193
Blog http://blogs.steeplesoft.com 



-- 
Jason Lee
Principal Member of Technical Staff
GlassFish Team

Oracle Corporation
Phone +1 405-216-3193
Blog http://blogs.steeplesoft.com 


-- 
Jason Lee
Principal Member of Technical Staff
GlassFish Team

Oracle Corporation
Phone +1 405-216-3193
Blog http://blogs.steeplesoft.com 


Diff for 18235

Jason Lee 04/19/2013

Re: Diff for 18235

Jason Lee 04/24/2013

Re: Diff for 18235

Tom Mueller 04/24/2013

Re: Diff for 18235

Jason Lee 04/24/2013

Re: Diff for 18235

Jason Lee 04/25/2013

Re: Diff for 18235

Tom Mueller 04/25/2013

Re: Diff for 18235

Jason Lee 04/25/2013

Re: Diff for 18235

Amy Roh 04/25/2013

Re: Diff for 18235

Jason Lee 04/25/2013

Re: Diff for 18235

Jason Lee 04/26/2013

Re: Diff for 18235

Amy Roh 04/26/2013

Re: Diff for 18235

Jason Lee 04/26/2013

Message not available

Re: Diff for 18235

Jason Lee 04/26/2013
 
 
Close
loading
Please Confirm
Close