Hi Mark,
You can probably override createRequest in your Application class to inject the
header before calling the parent version. Another way could be to add a
property in ERXApplication to "forceWebServerRequests".
public ERXRequest createRequest(String aMethod, String aURL, String
anHTTPVersion, Map<String, ? extends List<String>> someHeaders, NSData
aContent, Map<String, Object> someInfo) {
Regards,
Samuel
> Le 12 août 2019 à 09:01, Samuel Pelletier via Webobjects-dev
> <webobjects-dev@lists.apple.com> a écrit :
>
> 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 <mailto:webobjects-dev@lists.apple.com>> a
>> écrit :
>>
>>
>>
>>> On 12 Aug 2019, at 10:03, Matthew Ness via Webobjects-dev
>>> <webobjects-dev@lists.apple.com <mailto: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 <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
>> <mailto:Webobjects-dev@lists.apple.com>)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com
>> <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/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
