Hi Mark,

If you want to simulate a WOAdaotor environment and have the app generate 
static file URL, configure your load balancer to add 
"x-webobjects-adaptor-version" header like I do using apache reverse proxy:

RequestHeader set x-webobjects-adaptor-version "1"

Regards,

Samuel


> Le 12 août 2019 à 06:52, Mark Gowdy via Webobjects-dev 
> <webobjects-dev@lists.apple.com> a écrit :
> 
> 
> 
>> On 12 Aug 2019, at 10:03, Matthew Ness via Webobjects-dev 
>> <webobjects-dev@lists.apple.com> wrote:
>> 
>> 
>> 
>> On Sat, Aug 10, 2019, at 5:54 AM, Mark Gowdy via Webobjects-dev wrote:
>>> Hi.
>>> 
>>> Is anyone aware of any security issues (or other considerations) with 
>>> Direct Connect mode for a live deployment?
>>> 
>>> This will be using the Amazon’s Application Load Balancer.
>>> And it _might_ mean that I can ditch Apache once and for all :-)
>>> 
>>> Thanks, 
>>> 
>>> Mark
>> 
>> 
>> Hi Mark,
>> 
>> If you are applying a cert to your ALB, then SSL effectively terminates at 
>> that point and the request is forwarded on to your direct connect EC2 
>> instances.
>> I'm not sure what kind of security issues you are envisioning. Your should 
>> hold your EC2 instances security considerations to the same standard whether 
>> using Apache over 443 or your app on, say, 55555.
>> To that end, there should be no accessibility outside the above mentioned 
>> ALB connectivity and some administration bastion host for your terminal 
>> access.
>> 
>> Having said all that, if your application is completely session-less, then 
>> you're good to go.
>> 
>> If you have sessions in your app you still have some problems to overcome.
>> You can use session affinity (sticky sessions) in ALB/ELB (but not Network 
>> LB), but be aware they require cookies on the client.
>> So, you have the sticky sessions working, great! As your load balancer 
>> horizontally scales out, it's creating EC2 instances running your java app. 
>> But when your ALB decides to scale _in_, it'll wipe one or more of your EC2 
>> instances, which could still have active sessions.
>> So, unless you de-/serialise your Sessions at the start and end of the R-R 
>> loop and store that somewhere else (db/redis/etc) which your EC2 instances 
>> would have access to, it may annoy some users. 
>> Because of proprietary classes in WO, Session serialisation is unsolved and 
>> inflexible.
> 
> Wow..
> 
> Thanks for the info.
> 
> My apps have session, and I was planning on using sticky sessions with the 
> AWS’s ALB (Application Load Balancer).  I am aware of the cookie monster :-)
> 
> I will be using the ALB with an explicit list of AppServers, so I don’t 
> _think_ that will be a problem.  There will be no auto-scaling (for now).
> Basically, I plan to use ALB in the _similar_ way to Apache’s mod_proxy.
> 
> I tried session serialisation (in the DB) a long time ago, and it wasn’t an 
> ideal solution.. I would rather not go there.
> 
> I am happy enough with any network security concerns (i.e. nothing within the 
> VPC can be accessed externally).  The only way in is via the ALB (with SSL) 
> with SSL redirection rules etc..
> 
> My question was mainly around Direct Connect mode in the Application.
> e.g. I know it accesses the WebServer resources using a full system path in 
> the URL.
> But I know in that case it can’t access any files outside of its scope, so 
> that should be fine.
> 
> I just wanted to check if anyone knew of any security ‘gotchas’ I was unaware 
> when using DirectConnect.
> 
> Thanks, 
> 
> Mark
> 
>> 
>> 
>> Regards,
>> 
>> 
>> -- 
>> Matt
>> http://logicsquad.net
>> https://www.linkedin.com/company/logic-squad/
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/mark%40gowdy.co.uk
>> 
>> This email sent to m...@gowdy.co.uk
> 
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com
> 
> This email sent to sam...@samkar.com

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to