Re: Securing the deployment folders or at least the EOModel

Hello Mark

Thanks for the hint. How would one do encoding the EOModel folder and 
then decoding and loading it at run-time? Is there an easy way to 
accomplish that?

Best regards, Robert


> ----
>
> Message: 1
> Date: Tue, 7 Dec 2004 01:17:06 -0500
> From: Mark Ritchie <[email protected]>
> Subject: Re: Securing the deployment folders or at least the EOModel
> To: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> On Nov 26, 2004, at 12:25 PM, Chuck Hill wrote:
>> If they have root or physical access, there is nothing that you can do
>> to stop a determined reverse engineering attempt.  The best that you
>> can hope for is to slow them down and make it so tedious that they
>> give up.  One easy thing to do (or easy if you have not been using
>> deprecated API), is to package it all in one jar as in JBoss
>> deployments.  Then they at least have to unjar it to see the model.  A
>> further step would be to dispense with the file based model altogether
>> and create it in code.  You could even move these classes to their own
>> framework and obsfucate them.  And / or use encryption.  All of these
>> options represent a significant amount of effort and will only slow
>> down a determined attack.
> I agree with Chuck.  If the client is going to host the application
> then, at best, your only going to be able to slow down their alleged
> efforts to access the internal workings.  On this front, encoding the
> eomodel folder and then decoding and loading it a run-time might
> provide you with a level of security which is satisfactory.  However
> this will not withstand a developer who is capable of decompiling your
> java code for very long.
>
> On another front, have you considered hosting the application somewhere
> other then the client site?
> Perhaps you're willing to host the site yourself or you know of a 3rd
> party which will host it.
> That might be an option.
>
> Good luck!
> Mark.
> __
> Mark Ritchie, [email protected] 416-843-5479
> Software Developer, Apple Certified Developer Trainer
> WebObjects, Cocoa, Mac OS X and Mac OS X Server
> Diamond Lake Consulting Inc., Toronto, Ontario, Canada
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 7 Dec 2004 10:57:22 +0100
> From: "Patrick Schiess" <[email protected]>
> Subject: fcache Error
> To: <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain;	charset="us-ascii"
>
> Hi everybody,
>
> I'm running WebObjects 4.5.1 Patch 4 on W2k. I see constant error 
> messages
> from fcache in the Application Log of the
> Event Viewer complaining about a missing C:\Library\Fonts directory.
>
> Does anyone know how I can make it happy?
>
> I could create that directory but I'm far to be convinced this is the 
> good
> solution.
>
>> From where comes that process and what is its use?
> What launches it and how?
>
> Thanks,
> Patrick.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 7 Dec 2004 16:00:18 +0100
> From: Will Scheidegger <[email protected]>
> Subject: wo adaptor produces "broken pipe"s
> To: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> We're facing a weird problem all of a sudden. This one app ran fine for
> quite some time and now it chokes all the time and gives the following
> feedback in the log file:
>
> [2004-12-07 15:52:53 CET] <WorkerThread14> <WOWorkerThread id=14
> socket=Socket[addr=/192.168.1.40,port=
> 55917,localport=2007]> Exception while sending response:
> java.net.SocketException: Broken pipe
>
> After a bunch of these entries, usually we have lots of CLOSE_WAITs on
> the port of the application and the app becomes unavailable.
>
> Does anyone have a good idea on how to debug this? Thanks a bunch for
> your help!
>
> Regards,
> Will
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 7 Dec 2004 07:51:03 -0800
> From: Chuck Hill <[email protected]>
> Subject: Re: wo adaptor produces "broken pipe"s
> To: Will Scheidegger <[email protected]>
> Cc: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> This message means, "the source of this request has closed the
> connection".  Often this means that the user has hit stop or navigated
> somewhere else.  In  your case it probably means that the app too so
> long to respond that the adaptor gave up and went to another instance.
> Have the users been reporting "no instance available" or "your session
> has expired" errors?
>
> Unless you have changed the app, I would guess that you have some
> optimization work to do.  Likely you have exceeded some critical
> threshold in data size and processing is now taking longer than the
> woadaptor is prepared to wait.  Often this results from a slow fetch
> and simply adding a performance index will solve the problem.
> Otherwise, you will need to work on your code and / or start using the
> much dreaded WOLongResponsePage.  As an interim measure,  you can
> increase the Connect and Receive adaptor timeouts in JavaMonitor.
>
> I don't recall the CLOSE_WAIT problem being related to this.
>
>
> Chuck
>
>
> On Dec 7, 2004, at 7:00 AM, Will Scheidegger wrote:
>
>> We're facing a weird problem all of a sudden. This one app ran fine
>> for quite some time and now it chokes all the time and gives the
>> following feedback in the log file:
>>
>> [2004-12-07 15:52:53 CET] <WorkerThread14> <WOWorkerThread id=14
>> socket=Socket[addr=/192.168.1.40,port=
>> 55917,localport=2007]> Exception while sending response:
>> java.net.SocketException: Broken pipe
>>
>> After a bunch of these entries, usually we have lots of CLOSE_WAITs on
>> the port of the application and the app becomes unavailable.
>>
>> Does anyone have a good idea on how to debug this? Thanks a bunch for
>> your help!
>>
>> Regards,
>> Will
>>
>> _______________________________________________
>> WebObjects-admin mailing list
>> [email protected]
>> http://www.omnigroup.com/mailman/listinfo/webobjects-admin
>>
> -- 
> Practical WebObjects - a book for intermediate WebObjects developers
> who want to increase their overall knowledge of WebObjects, or those
> who are trying to solve specific application development problems.
> http://www.global-village.net/products/practical_webobjects
>
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 7 Dec 2004 17:35:10 +0100
> From: Will Scheidegger <[email protected]>
> Subject: Re: wo adaptor produces "broken pipe"s
> To: Chuck Hill <[email protected]>
> Cc: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Thanks for the quick and helpful reply. We're bashing our heads against
> the desk because we cannot seem to find the problem. We seem to have db
> connection problems... but we have not yet figured out what they are
> caused by.
>
> We'll keep trying... :-/
>
> Will
>
> On 07.12.2004, at 16:51, Chuck Hill wrote:
>
>> This message means, "the source of this request has closed the
>> connection".  Often this means that the user has hit stop or navigated
>> somewhere else.  In  your case it probably means that the app too so
>> long to respond that the adaptor gave up and went to another instance.
>>  Have the users been reporting "no instance available" or "your
>> session has expired" errors?
>>
>> Unless you have changed the app, I would guess that you have some
>> optimization work to do.  Likely you have exceeded some critical
>> threshold in data size and processing is now taking longer than the
>> woadaptor is prepared to wait.  Often this results from a slow fetch
>> and simply adding a performance index will solve the problem.
>> Otherwise, you will need to work on your code and / or start using the
>> much dreaded WOLongResponsePage.  As an interim measure,  you can
>> increase the Connect and Receive adaptor timeouts in JavaMonitor.
>>
>> I don't recall the CLOSE_WAIT problem being related to this.
>>
>>
>> Chuck
>>
>>
>> On Dec 7, 2004, at 7:00 AM, Will Scheidegger wrote:
>>
>>> We're facing a weird problem all of a sudden. This one app ran fine
>>> for quite some time and now it chokes all the time and gives the
>>> following feedback in the log file:
>>>
>>> [2004-12-07 15:52:53 CET] <WorkerThread14> <WOWorkerThread id=14
>>> socket=Socket[addr=/192.168.1.40,port=
>>> 55917,localport=2007]> Exception while sending response:
>>> java.net.SocketException: Broken pipe
>>>
>>> After a bunch of these entries, usually we have lots of CLOSE_WAITs
>>> on the port of the application and the app becomes unavailable.
>>>
>>> Does anyone have a good idea on how to debug this? Thanks a bunch for
>>> your help!
>>>
>>> Regards,
>>> Will
>>>
>>> _______________________________________________
>>> WebObjects-admin mailing list
>>> [email protected]
>>> http://www.omnigroup.com/mailman/listinfo/webobjects-admin
>>>
>> -- 
>> Practical WebObjects - a book for intermediate WebObjects developers
>> who want to increase their overall knowledge of WebObjects, or those
>> who are trying to solve specific application development problems.
>> http://www.global-village.net/products/practical_webobjects
>>
>>
>>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 7 Dec 2004 17:46:05 +0100
> From: Will Scheidegger <[email protected]>
> Subject: [Solved by workaround]: wo adaptor produces "broken pipe"s
> To: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Thanks Chuck. We now were able solve the problem with a workaround....
> for now.
>
> Regards,
> Will
>
> On 07.12.2004, at 17:35, Will Scheidegger wrote:
>
>> Thanks for the quick and helpful reply. We're bashing our heads
>> against the desk because we cannot seem to find the problem. We seem
>> to have db connection problems... but we have not yet figured out what
>> they are caused by.
>>
>> We'll keep trying... :-/
>>
>> Will
>>
>> On 07.12.2004, at 16:51, Chuck Hill wrote:
>>
>>> This message means, "the source of this request has closed the
>>> connection".  Often this means that the user has hit stop or
>>> navigated somewhere else.  In  your case it probably means that the
>>> app too so long to respond that the adaptor gave up and went to
>>> another instance.  Have the users been reporting "no instance
>>> available" or "your session has expired" errors?
>>>
>>> Unless you have changed the app, I would guess that you have some
>>> optimization work to do.  Likely you have exceeded some critical
>>> threshold in data size and processing is now taking longer than the
>>> woadaptor is prepared to wait.  Often this results from a slow fetch
>>> and simply adding a performance index will solve the problem.
>>> Otherwise, you will need to work on your code and / or start using
>>> the much dreaded WOLongResponsePage.  As an interim measure,  you can
>>> increase the Connect and Receive adaptor timeouts in JavaMonitor.
>>>
>>> I don't recall the CLOSE_WAIT problem being related to this.
>>>
>>>
>>> Chuck
>>>
>>>
>>> On Dec 7, 2004, at 7:00 AM, Will Scheidegger wrote:
>>>
>>>> We're facing a weird problem all of a sudden. This one app ran fine
>>>> for quite some time and now it chokes all the time and gives the
>>>> following feedback in the log file:
>>>>
>>>> [2004-12-07 15:52:53 CET] <WorkerThread14> <WOWorkerThread id=14
>>>> socket=Socket[addr=/192.168.1.40,port=
>>>> 55917,localport=2007]> Exception while sending response:
>>>> java.net.SocketException: Broken pipe
>>>>
>>>> After a bunch of these entries, usually we have lots of CLOSE_WAITs
>>>> on the port of the application and the app becomes unavailable.
>>>>
>>>> Does anyone have a good idea on how to debug this? Thanks a bunch
>>>> for your help!
>>>>
>>>> Regards,
>>>> Will
>>>>
>>>> _______________________________________________
>>>> WebObjects-admin mailing list
>>>> [email protected]
>>>> http://www.omnigroup.com/mailman/listinfo/webobjects-admin
>>>>
>>> -- 
>>> Practical WebObjects - a book for intermediate WebObjects developers
>>> who want to increase their overall knowledge of WebObjects, or those
>>> who are trying to solve specific application development problems.
>>> http://www.global-village.net/products/practical_webobjects
>>>
>>>
>>>
>>
>> _______________________________________________
>> WebObjects-admin mailing list
>> [email protected]
>> http://www.omnigroup.com/mailman/listinfo/webobjects-admin
>
>
>
> ------------------------------
>
> _______________________________________________
> WebObjects-admin mailing list
> [email protected]
> http://www.omnigroup.com/mailman/listinfo/webobjects-admin
>
>
> End of WebObjects-admin Digest, Vol 12, Issue 2
> ***********************************************
>
>

_/ _/ _/ _/ _/                             r. huber
               _/
            _/      _/      _/           7r gmbh
         _/      _/  _/               lindenplatz 12b
      _/      _//                   ch-8203 schaffhausen
   _/      _/
_/      _/                    tel. +41 52 624 81 15   www.seven-r.ch