You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Stanczak Group <ju...@stanczakgroup.com> on 2005/03/10 11:08:40 UTC
Secure Files
As part of my current app I have a place to upload files. These files
are saved to the file system and later accessed. These files should only
be accessed by logged in users. So how would I go about securing these
in my Tapestry app. What I had in mind first was having all requests for
files go thought a servlet that checks login status and then uses an
stream to send the file to the client, but I'm open to any suggestions.
--
Justin Stanczak
Stanczak Group
812-735-3600
"All that is necessary for the triumph of evil is that good men do nothing."
Edmund Burke
..________...............__.................
./ _____/..____..._____/..|_..____...____....
/...\..____/.__.\./....\...__\/.._.\./._..\....
\....\_\..\..___/|...|..\..|.(..<_>.|.<_>..)....
.\______../\___.._\__|../__|..\____/.\____/......
........\/.....\/.....\/..........................
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
AW: Secure Files
Posted by Gregor Melhorn <g....@web.de>.
Thanks for your reply...
> I'd take a more basic approach to replicate the file... I don't know
> how easy Coda is to administer but I have experience with Windows
> replication and it is anything straightforward. I'd set some simple
> rsync scheduled tasks.
> Btw, are you sure you'll need a cluster/failover system? A well built
> linux server with raid 1 arrays can give a very high uptime.
The backup is only a secondary problem. Reliability could be improved by
using a raid system, as you said. The cluster consists of Tomcat with Apache
using mod_jk, allowing for sticky sessions. I really only want clustering
for performance reasons.
If using coda, I can put a hard drive on every imageserver, and the file
will be immediately available to all other servers after it was uploaded.
After googling for rsyc it looks to me as if it only allows for backups,
correct me if I'm wrong.
> That is not worth to have another service. Tomcat is very performance
> for static content. I find it hard enough to tune tomcat's
> performance... Adding apache would complicate the task quite a bit.
Well, that depends... If using every web server as an image server, network
load increases, since every image upload must be propagated to all the other
servers. If using separate image servers, I have to find a way to secure the
files on them, maybe using an encryption algorithm for the image location
together with a timestamp on the tapestry side, and then on the image server
decrypting the code with a custom http handler or something like that, using
a time out of one minute or so. This could be managed by using an algorithm
with public and private key system.
I don't have experience on this, maybe it would inflict performance so it
does not make up for performance compared to the additional network load on
the combined approach.
Gregor
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Secure Files
Posted by Henri Dupre <he...@gmail.com>.
> I think I've got several choices on saving image files. One possibility
> would be saving the images to the database. Not a good plan I suppose, since
> MySQL Cluster is an in-memory-database and I'll most certainly run out of
> ram with this. Databases are not for saving large binary data...
I'm not sure how well mysql would handle that... And it seems to that
it would require way more processing to output a poor image.
> Another approach would be using a large harddrive in every webserver, and a
> network based filesystem as Coda, that automatically takes care of failover
> and updating the copies via the network.
I'd take a more basic approach to replicate the file... I don't know
how easy Coda is to administer but I have experience with Windows
replication and it is anything straightforward. I'd set some simple
rsync scheduled tasks.
Btw, are you sure you'll need a cluster/failover system? A well built
linux server with raid 1 arrays can give a very high uptime.
> For serving the images I might use a tapestry service, that accesses the
> files via the local filesystem, or use a separate image server, that
> tapestry will only generate links. With the separate image server, I
> currently have no plans on how to implement security with this, though.
That is not worth to have another service. Tomcat is very performant
for static content. I find it hard enough to tune tomcat's
performance... Adding apache would complicate the task quite a bit.
> By the way, this list is fantastic, it's really good to see so many people
> sharing their experience with others...
Yes absolutly, if it was a searchable forum it would be even better
but the community behind tapestry is incredible!!
Henri.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Scale and rotate images
Posted by Barry Books <bf...@mac.com>.
The code evolved over the years but ended up using the 1.4 image routines that don't require X.
We had reliability problems with every method we tried. What finally worked was creating the
webservice that ran in its own tomcat. We the load balanced them and added some external code to
restart them when they quit.
> I am curious. What formats did you manage to manipulate on the server side ?
>Did you use AWT to do it ?
>I need to manipulate(crop mainly) gif jpeg png & wbmp, but currently plan to do it outside java as I >don't quite trust it to be reliably implemented in Java. Am I mistaken ?
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Scale and rotate images
Posted by Gabe <gh...@ekosystems.com>.
I've done that using JAI (Java advanced imaging). I did some scaling
and rotating of images about a year ago and the results were good. (I
think it tries to use native stuff if its available for the platform).
Not sure if java 1.5 has this integrated in or if its still a separate
package.
-gabe
On Mar 15, 2005, at 5:44 PM, Henrik Vendelbo wrote:
> I am curious. What formats did you manage to manipulate on the server
> side ?
> Did you use AWT to do it ?
>
> I need to manipulate(crop mainly) gif jpeg png & wbmp, but currently
> plan to do it outside java as I don't quite trust it to be reliably
> implemented in Java. Am I mistaken ?
>
> Henrik
>
> ----- Original Message -----
> From: "Barry Books" <bf...@mac.com>
> To: "Tapestry users" <ta...@jakarta.apache.org>
> Sent: Monday, March 14, 2005 2:10 PM
> Subject: Re: AW: AW: Secure Files
>
>
>>> I suppose with "key" you mean a unique image identifier (aka primary
>>> key),
>>> not something with encryption.
>> Yes I meant database key. I also just named the file from the key so
>> the filename
>> for and image with a primary key of 1234 would be 1234.jpg
>>
>>> It would be best if I could avoid requests to the database server
>>> from the
>>> image server, so there is only one request to the database for the
>>> construction of the tapestry page.
>> If your images never change then you would not need to hit the
>> database to
>> determine the last modified time. My images could change.
>>
>>> Problem with this is security - even with random filenames it would
>>> be
>>> possible to post them somewhere and send the links around to users
>>> without
>>> permission. In my last reply I explained how this could be avoided
>>> using an
>>> encrypted string for the key that contains the primary key of the
>>> image and
>>> an additional timestamp.
>>
>> If the images are served from the cache thru a service you can apply
>> any securtiy
>> you like. The images would not be directly accessible.
>>
>>> Regarding image storage:
>>
>>> Using coda the local caching is done automatically, and depending on
>>> configuration the file is either received from a central repository
>>> and
>>> cached if a user requests it or it is distributed to all servers on
>>> file
>>> upload (so every server always has an up-to-date copy on his hard
>>> drive).
>>> The synchronization happens transparently at disk IO level, so I
>>> don't have
>>> to care about it in my application. If a server goes down and misses
>>> some
>>> file uploads, it will receive them transparently from other servers
>>> after
>>> the images are requested.
>>
>> Perhaps coda could do this but I had over 500gig of images but only
>> 40gig drives
>> on the webserver. The method above allows this to happen
>> transparently.
>>
>> I also built some smarts into my image webservice. It could scale and
>> rotate images
>> and since I had my images in the database I had multiple ones load
>> balanced.
>>
>> Barry
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Scale and rotate images
Posted by Henrik Vendelbo <hv...@bluprints.com>.
I am curious. What formats did you manage to manipulate on the server side ?
Did you use AWT to do it ?
I need to manipulate(crop mainly) gif jpeg png & wbmp, but currently plan to do it outside java as I don't quite trust it to be reliably implemented in Java. Am I mistaken ?
Henrik
----- Original Message -----
From: "Barry Books" <bf...@mac.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Monday, March 14, 2005 2:10 PM
Subject: Re: AW: AW: Secure Files
> >I suppose with "key" you mean a unique image identifier (aka primary key),
> >not something with encryption.
> Yes I meant database key. I also just named the file from the key so the filename
> for and image with a primary key of 1234 would be 1234.jpg
>
> >It would be best if I could avoid requests to the database server from the
> >image server, so there is only one request to the database for the
> >construction of the tapestry page.
> If your images never change then you would not need to hit the database to
> determine the last modified time. My images could change.
>
> >Problem with this is security - even with random filenames it would be
> >possible to post them somewhere and send the links around to users without
> >permission. In my last reply I explained how this could be avoided using an
> >encrypted string for the key that contains the primary key of the image and
> >an additional timestamp.
>
> If the images are served from the cache thru a service you can apply any securtiy
> you like. The images would not be directly accessible.
>
> >Regarding image storage:
>
> >Using coda the local caching is done automatically, and depending on
> >configuration the file is either received from a central repository and
> >cached if a user requests it or it is distributed to all servers on file
> >upload (so every server always has an up-to-date copy on his hard drive).
> >The synchronization happens transparently at disk IO level, so I don't have
> >to care about it in my application. If a server goes down and misses some
> >file uploads, it will receive them transparently from other servers after
> >the images are requested.
>
> Perhaps coda could do this but I had over 500gig of images but only 40gig drives
> on the webserver. The method above allows this to happen transparently.
>
> I also built some smarts into my image webservice. It could scale and rotate images
> and since I had my images in the database I had multiple ones load balanced.
>
> Barry
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
AW: AW: AW: Secure Files
Posted by Gregor Melhorn <g....@web.de>.
I'd also be interested in this for obvious reasons :-)
Gregor
-----Ursprüngliche Nachricht-----
Von: tapestry-user-return-18230-g.melhorn=web.de@jakarta.apache.org
[mailto:tapestry-user-return-18230-g.melhorn=web.de@jakarta.apache.org] Im
Auftrag von Henri Dupre
Gesendet: Mittwoch, 16. März 2005 20:03
An: Tapestry users
Betreff: Re: AW: AW: Secure Files
On Wed, 16 Mar 2005 01:01:15 -0000, Henrik Vendelbo
<hv...@bluprints.com> wrote:
> I created a slightly modified Base64 (one that can be used in an url
without problems) and use 12 char id's which equals 8byte integer. That is
plenty. If you have a million immages it will still make the chance of
guessing a valid file Id once you have the key and the algorithm less than 1
to 10^10.
I'd be interested to see your code for that Base64. I will need
something similar but for very different reasons (I'd like to pass
stuff in the url but not make it too obvious).
Henri.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
AW: AW: AW: Secure Files
Posted by Gregor Melhorn <g....@web.de>.
If I'm getting it right, you're using the same encryption key String
throughout the application, is that correct?
With this approach, images never "time out" and it would be possible to send
the links around, though only an initially authorized user could do this.
If using another encoding algorithm, you can avoid the need for randomized
filenames.
If the web server and image server are on the same machine (at least if the
session is replicated on them), you can generate a random string on user
logon and store this key in the session. Later on use this string for
decryption.
After googling around for a while I'd suggest this:
Generate a service interface for general crypto. The interface specifies a
javax.security.Key getRandomKey() method, an encode(String toEncode,
javax.security.Key key) and a decode(String toDecode, javax.Security.Key
key) method.
Then I'd generate a service implementation for the blowfish algorithm,
adapting from the javax.crypto package.
Then there should be another service interface, yet I don't have a name for
this. This is some kind of simplified crypto service, that takes care of key
storage itself. So there is only an encode(String toEncode) and a
decode(String toDecode) method on it.
On encryption, this service checks for the existence of a key in the
session, if none is present, it will generate one and store it in a known
location in the session. Then this key is used for encryption.
For decryption, if no key is present in the session, an exception is thrown,
else the key from the session is used. I'd suggest using a checksum for
encryption and decryption, just in case someone with a valid key in the
session is passing in random urls, and generate another exception for wrong
checksum.
I'd then write a tapesty image service and inject the POJO implementation of
the simplified crypto service.
This way the same encryption method can be used throughout the application,
just in case there are other services that have a need for crypto services.
I'm planning to implement this soon; let me know if you are interested, and
as always suggestions/improvements are welcome.
Regards
Gregor
-----Ursprüngliche Nachricht-----
Von: tapestry-user-return-18264-g.melhorn=web.de@jakarta.apache.org
[mailto:tapestry-user-return-18264-g.melhorn=web.de@jakarta.apache.org] Im
Auftrag von Henrik Vendelbo
Gesendet: Donnerstag, 17. März 2005 16:11
An: Tapestry users; Henri Dupre
Betreff: Re: AW: AW: Secure Files
I think I used a Base64 util class from one of the apache projects, don't
recall which one and simply changed the string used for converting back and
forth, in this case I only need one way.
Essentially + and - signs should work in most internet related situations,
while the original / wouldn't work
I assume that someone could suggest even better choices. + might spoil
things for some situations and _ might be a better choice. Anyway you
wouldn't want to use : . / ? # @ & =
public class RandomTokenFactory extends Random {
private static final long serialVersionUID = 10000L;
final static String baseTable =
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+-";
public RandomTokenFactory() {
super();
}
public RandomTokenFactory(long seed) {
super(seed);
}
public String getToken8() {
byte[] buf = new byte[6];
nextBytes(buf);
return encode(buf);
}
public String getToken12() {
byte[] buf = new byte[9];
nextBytes(buf);
return encode(buf);
}
/**
* Encode a byte array.
*
* @param bytes a byte array to be encoded.
* @return encoded object as a String object.
*/
public static String encode(byte[] bytes) {
StringBuffer tmp = new StringBuffer();
int i = 0;
byte pos;
for(i=0; i < (bytes.length - bytes.length%3); i+=3) {
pos = (byte) ((bytes[i] >> 2) & 63);
tmp.append(baseTable.charAt(pos));
pos = (byte) (((bytes[i] & 3) << 4) + ((bytes[i+1] >> 4) & 15));
tmp.append(baseTable.charAt( pos ));
pos = (byte) (((bytes[i+1] & 15) << 2) + ((bytes[i+2] >> 6) & 3));
tmp.append(baseTable.charAt(pos));
pos = (byte) (((bytes[i+2]) & 63));
tmp.append(baseTable.charAt(pos));
// Add a new line for each 76 chars.
// 76*3/4 = 57
if(((i+2)%56) == 0) {
tmp.append("\r\n");
}
}
if(bytes.length % 3 != 0) {
if(bytes.length % 3 == 2) {
pos = (byte) ((bytes[i] >> 2) & 63);
tmp.append(baseTable.charAt(pos));
pos = (byte) (((bytes[i] & 3) << 4) + ((bytes[i+1] >> 4) & 15));
tmp.append(baseTable.charAt( pos ));
pos = (byte) ((bytes[i+1] & 15) << 2);
tmp.append(baseTable.charAt(pos));
tmp.append("=");
} else if(bytes.length % 3 == 1) {
pos = (byte) ((bytes[i] >> 2) & 63);
tmp.append(baseTable.charAt(pos));
pos = (byte) ((bytes[i] & 3) << 4);
tmp.append(baseTable.charAt( pos ));
tmp.append("==");
}
}
return tmp.toString();
}
/**
* Encode a String object.
*
* @param src a String object to be encoded with Base64 schema.
* @return encoded String object.
*/
public static String encode(String src) {
return encode(src.getBytes());
}
public static byte[] decode(String src) throws ValidationProblemException {
byte[] bytes = null;
StringBuffer buf = new StringBuffer(src);
// First, Remove white spaces (\r\n, \t, " ");
int i = 0;
char c = ' ';
char oc = ' ';
while( i < buf.length()) {
oc = c;
c = buf.charAt(i);
if( oc == '\r' && c == '\n') {
buf.deleteCharAt(i);
buf.deleteCharAt(i-1);
i -= 2;
} else if( c == '\t') {
buf.deleteCharAt(i);
i --;
} else if( c == ' ') {
i --;
}
i++;
}
// The source should consists groups with length of 4 chars.
if(buf.length() % 4 != 0) {
throw new ValidationProblemException("Base64 decoding invalid length");
}
// pre-set byte array size.
bytes = new byte[3 * (buf.length() / 4)];
//int len = 3 * (buf.length() % 4);
//System.out.println("Size of Bytes array: " + len);
int index = 0;
// Now decode each group
for(i = 0; i < buf.length(); i+=4) {
byte data = 0;
int nGroup = 0;
for(int j = 0; j < 4; j++) {
char theChar = buf.charAt(i + j);
if(theChar == '=') {
data = 0;
} else {
data = getBaseTableIndex(theChar);
}
if(data == -1) {
throw new ValidationProblemException("Base64 decoding bad character");
}
nGroup = 64*nGroup + data;
}
bytes[index] = (byte) (255 & (nGroup >> 16));
index ++;
bytes[index] = (byte) (255 & (nGroup >> 8));
index ++;
bytes[index] = (byte) (255 & (nGroup));
index ++;
}
byte[] newBytes = new byte[index];
for(i = 0; i < index; i++) {
newBytes[i] = bytes[i];
}
return newBytes;
}
/**
* Find index number in base table for a given character.
*
*/
protected static byte getBaseTableIndex(char c) {
byte index = -1;
for(byte i = 0; i < baseTable.length(); i ++) {
if(baseTable.charAt(i) == c) {
index = i;
break;
}
}
return index;
}
}
----- Original Message -----
From: "Henri Dupre" <he...@gmail.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Wednesday, March 16, 2005 7:02 PM
Subject: Re: AW: AW: Secure Files
> On Wed, 16 Mar 2005 01:01:15 -0000, Henrik Vendelbo
> <hv...@bluprints.com> wrote:
> > I created a slightly modified Base64 (one that can be used in an url
without problems) and use 12 char id's which equals 8byte integer. That is
plenty. If you have a million immages it will still make the chance of
guessing a valid file Id once you have the key and the algorithm less than 1
to 10^10.
>
> I'd be interested to see your code for that Base64. I will need
> something similar but for very different reasons (I'd like to pass
> stuff in the url but not make it too obvious).
>
> Henri.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: AW: AW: Secure Files
Posted by Henrik Vendelbo <hv...@bluprints.com>.
I think I used a Base64 util class from one of the apache projects, don't recall which one and simply changed the string used for converting back and forth, in this case I only need one way.
Essentially + and - signs should work in most internet related situations, while the original / wouldn't work
I assume that someone could suggest even better choices. + might spoil things for some situations and _ might be a better choice. Anyway you wouldn't want to use : . / ? # @ & =
public class RandomTokenFactory extends Random {
private static final long serialVersionUID = 10000L;
final static String baseTable = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+-";
public RandomTokenFactory() {
super();
}
public RandomTokenFactory(long seed) {
super(seed);
}
public String getToken8() {
byte[] buf = new byte[6];
nextBytes(buf);
return encode(buf);
}
public String getToken12() {
byte[] buf = new byte[9];
nextBytes(buf);
return encode(buf);
}
/**
* Encode a byte array.
*
* @param bytes a byte array to be encoded.
* @return encoded object as a String object.
*/
public static String encode(byte[] bytes) {
StringBuffer tmp = new StringBuffer();
int i = 0;
byte pos;
for(i=0; i < (bytes.length - bytes.length%3); i+=3) {
pos = (byte) ((bytes[i] >> 2) & 63);
tmp.append(baseTable.charAt(pos));
pos = (byte) (((bytes[i] & 3) << 4) + ((bytes[i+1] >> 4) & 15));
tmp.append(baseTable.charAt( pos ));
pos = (byte) (((bytes[i+1] & 15) << 2) + ((bytes[i+2] >> 6) & 3));
tmp.append(baseTable.charAt(pos));
pos = (byte) (((bytes[i+2]) & 63));
tmp.append(baseTable.charAt(pos));
// Add a new line for each 76 chars.
// 76*3/4 = 57
if(((i+2)%56) == 0) {
tmp.append("\r\n");
}
}
if(bytes.length % 3 != 0) {
if(bytes.length % 3 == 2) {
pos = (byte) ((bytes[i] >> 2) & 63);
tmp.append(baseTable.charAt(pos));
pos = (byte) (((bytes[i] & 3) << 4) + ((bytes[i+1] >> 4) & 15));
tmp.append(baseTable.charAt( pos ));
pos = (byte) ((bytes[i+1] & 15) << 2);
tmp.append(baseTable.charAt(pos));
tmp.append("=");
} else if(bytes.length % 3 == 1) {
pos = (byte) ((bytes[i] >> 2) & 63);
tmp.append(baseTable.charAt(pos));
pos = (byte) ((bytes[i] & 3) << 4);
tmp.append(baseTable.charAt( pos ));
tmp.append("==");
}
}
return tmp.toString();
}
/**
* Encode a String object.
*
* @param src a String object to be encoded with Base64 schema.
* @return encoded String object.
*/
public static String encode(String src) {
return encode(src.getBytes());
}
public static byte[] decode(String src) throws ValidationProblemException {
byte[] bytes = null;
StringBuffer buf = new StringBuffer(src);
// First, Remove white spaces (\r\n, \t, " ");
int i = 0;
char c = ' ';
char oc = ' ';
while( i < buf.length()) {
oc = c;
c = buf.charAt(i);
if( oc == '\r' && c == '\n') {
buf.deleteCharAt(i);
buf.deleteCharAt(i-1);
i -= 2;
} else if( c == '\t') {
buf.deleteCharAt(i);
i --;
} else if( c == ' ') {
i --;
}
i++;
}
// The source should consists groups with length of 4 chars.
if(buf.length() % 4 != 0) {
throw new ValidationProblemException("Base64 decoding invalid length");
}
// pre-set byte array size.
bytes = new byte[3 * (buf.length() / 4)];
//int len = 3 * (buf.length() % 4);
//System.out.println("Size of Bytes array: " + len);
int index = 0;
// Now decode each group
for(i = 0; i < buf.length(); i+=4) {
byte data = 0;
int nGroup = 0;
for(int j = 0; j < 4; j++) {
char theChar = buf.charAt(i + j);
if(theChar == '=') {
data = 0;
} else {
data = getBaseTableIndex(theChar);
}
if(data == -1) {
throw new ValidationProblemException("Base64 decoding bad character");
}
nGroup = 64*nGroup + data;
}
bytes[index] = (byte) (255 & (nGroup >> 16));
index ++;
bytes[index] = (byte) (255 & (nGroup >> 8));
index ++;
bytes[index] = (byte) (255 & (nGroup));
index ++;
}
byte[] newBytes = new byte[index];
for(i = 0; i < index; i++) {
newBytes[i] = bytes[i];
}
return newBytes;
}
/**
* Find index number in base table for a given character.
*
*/
protected static byte getBaseTableIndex(char c) {
byte index = -1;
for(byte i = 0; i < baseTable.length(); i ++) {
if(baseTable.charAt(i) == c) {
index = i;
break;
}
}
return index;
}
}
----- Original Message -----
From: "Henri Dupre" <he...@gmail.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Wednesday, March 16, 2005 7:02 PM
Subject: Re: AW: AW: Secure Files
> On Wed, 16 Mar 2005 01:01:15 -0000, Henrik Vendelbo
> <hv...@bluprints.com> wrote:
> > I created a slightly modified Base64 (one that can be used in an url without problems) and use 12 char id's which equals 8byte integer. That is plenty. If you have a million immages it will still make the chance of guessing a valid file Id once you have the key and the algorithm less than 1 to 10^10.
>
> I'd be interested to see your code for that Base64. I will need
> something similar but for very different reasons (I'd like to pass
> stuff in the url but not make it too obvious).
>
> Henri.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: AW: AW: Secure Files
Posted by Henri Dupre <he...@gmail.com>.
On Wed, 16 Mar 2005 01:01:15 -0000, Henrik Vendelbo
<hv...@bluprints.com> wrote:
> I created a slightly modified Base64 (one that can be used in an url without problems) and use 12 char id's which equals 8byte integer. That is plenty. If you have a million immages it will still make the chance of guessing a valid file Id once you have the key and the algorithm less than 1 to 10^10.
I'd be interested to see your code for that Base64. I will need
something similar but for very different reasons (I'd like to pass
stuff in the url but not make it too obvious).
Henri.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: AW: AW: Secure Files
Posted by Henrik Vendelbo <hv...@bluprints.com>.
I created a slightly modified Base64 (one that can be used in an url without problems) and use 12 char id's which equals 8byte integer. That is plenty. If you have a million immages it will still make the chance of guessing a valid file Id once you have the key and the algorithm less than 1 to 10^10.
----- Original Message -----
From: "Gregor Melhorn" <g....@web.de>
To: "'Tapestry users'" <ta...@jakarta.apache.org>
Sent: Tuesday, March 15, 2005 11:29 PM
Subject: AW: AW: AW: Secure Files
Good point.
Actually access is not the same for all users, so I'll use random strings
for filenames, what do you think will be enough? 16 characters? It just
should be enough for guessing to be ineffective. Too many characters would
mean wasting db server resources, since I'll have to save the filename to
the db.
The files will then locally be saved in a subdirectory corresponding to the
username, so just in case I need to fix something by hand, I don't get lost.
So files for the user "user" will get saved in u/s/e/user
I think I'll write some "secure file" service for this, though I must admit
I didn't ever write a service before, and at present I also have no idea how
to solve it best.
Writing the decryption part shouldn't be a problem, just use the script from
the session and stream the response to the client.
But how can encryption be done in a reusable way? I know I could write a
simple image component that generates links from filenames, but I think
there should be a way that seamlessly integrates into tapestry so other
components could benefit from it, too.
-----Ursprüngliche Nachricht-----
Von: tapestry-user-return-18192-g.melhorn=web.de@jakarta.apache.org
[mailto:tapestry-user-return-18192-g.melhorn=web.de@jakarta.apache.org] Im
Auftrag von Henrik Vendelbo
Gesendet: Mittwoch, 16. März 2005 00:01
An: Tapestry users
Betreff: Re: AW: AW: Secure Files
Looks like a good plan.
I assume that those users who are allowed access to the system should have
access to all files.
Otherwise you would need to have a good deal of randomness in internal image
file names as well, or your algorithm could be guessed and any person with
access to one file could gain access to all.
Very interesting discussion btw.
----- Original Message -----
From: "Gregor Melhorn" <g....@web.de>
To: "'Tapestry users'" <ta...@jakarta.apache.org>
Sent: Monday, March 14, 2005 10:01 PM
Subject: AW: AW: AW: Secure Files
> > Perhaps coda could do this but I had over 500gig of images but only
40gig
> > drives on the web server. The method above allows this to happen
> > transparently.
>
> So basically you did just the same as coda would do - only you saved the
> files to the database and took care of caching and updating yourself. Did
I
> get this right?
>
> I found out I don't need separate image servers. Coda uses Multicast RCP
for
> updating files, so there is virtually no increase in network traffic if
> using more servers, correct me if I'm wrong.
>
> Basically this means I can use Coda as a file system, propagating changes
> via Multicast and handle everything else, e.g. security, in tapestry as if
> I'm using local files and don't have to care about clustering, without a
> performance penalty compared to local access except when updating files.
>
> Security would work like that (following some website I found about that):
>
> 1. Let the system generate a random key when a user logs on and store it
in
> the session (e.g in the user object).
>
> 2. Encrypt any protected image filename using that key. The check if user
> may access the file is done here, if he may not, no URL is generated.
>
> 3. On the image service, check for existence of the user object in the
> session, and decrypt the supplied filename using the key from the user
> object.
>
> 3. Read the image from the file system and stream it to the client.
>
> This should work for non-clustered systems, too.
>
> Is it better to use a tapestry service or a servlet for that kind of job?
>
> Regards
> Gregor
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
AW: AW: AW: Secure Files
Posted by Gregor Melhorn <g....@web.de>.
Good point.
Actually access is not the same for all users, so I'll use random strings
for filenames, what do you think will be enough? 16 characters? It just
should be enough for guessing to be ineffective. Too many characters would
mean wasting db server resources, since I'll have to save the filename to
the db.
The files will then locally be saved in a subdirectory corresponding to the
username, so just in case I need to fix something by hand, I don't get lost.
So files for the user "user" will get saved in u/s/e/user
I think I'll write some "secure file" service for this, though I must admit
I didn't ever write a service before, and at present I also have no idea how
to solve it best.
Writing the decryption part shouldn't be a problem, just use the script from
the session and stream the response to the client.
But how can encryption be done in a reusable way? I know I could write a
simple image component that generates links from filenames, but I think
there should be a way that seamlessly integrates into tapestry so other
components could benefit from it, too.
-----Ursprüngliche Nachricht-----
Von: tapestry-user-return-18192-g.melhorn=web.de@jakarta.apache.org
[mailto:tapestry-user-return-18192-g.melhorn=web.de@jakarta.apache.org] Im
Auftrag von Henrik Vendelbo
Gesendet: Mittwoch, 16. März 2005 00:01
An: Tapestry users
Betreff: Re: AW: AW: Secure Files
Looks like a good plan.
I assume that those users who are allowed access to the system should have
access to all files.
Otherwise you would need to have a good deal of randomness in internal image
file names as well, or your algorithm could be guessed and any person with
access to one file could gain access to all.
Very interesting discussion btw.
----- Original Message -----
From: "Gregor Melhorn" <g....@web.de>
To: "'Tapestry users'" <ta...@jakarta.apache.org>
Sent: Monday, March 14, 2005 10:01 PM
Subject: AW: AW: AW: Secure Files
> > Perhaps coda could do this but I had over 500gig of images but only
40gig
> > drives on the web server. The method above allows this to happen
> > transparently.
>
> So basically you did just the same as coda would do - only you saved the
> files to the database and took care of caching and updating yourself. Did
I
> get this right?
>
> I found out I don't need separate image servers. Coda uses Multicast RCP
for
> updating files, so there is virtually no increase in network traffic if
> using more servers, correct me if I'm wrong.
>
> Basically this means I can use Coda as a file system, propagating changes
> via Multicast and handle everything else, e.g. security, in tapestry as if
> I'm using local files and don't have to care about clustering, without a
> performance penalty compared to local access except when updating files.
>
> Security would work like that (following some website I found about that):
>
> 1. Let the system generate a random key when a user logs on and store it
in
> the session (e.g in the user object).
>
> 2. Encrypt any protected image filename using that key. The check if user
> may access the file is done here, if he may not, no URL is generated.
>
> 3. On the image service, check for existence of the user object in the
> session, and decrypt the supplied filename using the key from the user
> object.
>
> 3. Read the image from the file system and stream it to the client.
>
> This should work for non-clustered systems, too.
>
> Is it better to use a tapestry service or a servlet for that kind of job?
>
> Regards
> Gregor
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: AW: AW: Secure Files
Posted by Henrik Vendelbo <hv...@bluprints.com>.
Looks like a good plan.
I assume that those users who are allowed access to the system should have access to all files.
Otherwise you would need to have a good deal of randomness in internal image file names as well, or your algorithm could be guessed and any person with access to one file could gain access to all.
Very interesting discussion btw.
----- Original Message -----
From: "Gregor Melhorn" <g....@web.de>
To: "'Tapestry users'" <ta...@jakarta.apache.org>
Sent: Monday, March 14, 2005 10:01 PM
Subject: AW: AW: AW: Secure Files
> > Perhaps coda could do this but I had over 500gig of images but only 40gig
> > drives on the web server. The method above allows this to happen
> > transparently.
>
> So basically you did just the same as coda would do - only you saved the
> files to the database and took care of caching and updating yourself. Did I
> get this right?
>
> I found out I don't need separate image servers. Coda uses Multicast RCP for
> updating files, so there is virtually no increase in network traffic if
> using more servers, correct me if I'm wrong.
>
> Basically this means I can use Coda as a file system, propagating changes
> via Multicast and handle everything else, e.g. security, in tapestry as if
> I'm using local files and don't have to care about clustering, without a
> performance penalty compared to local access except when updating files.
>
> Security would work like that (following some website I found about that):
>
> 1. Let the system generate a random key when a user logs on and store it in
> the session (e.g in the user object).
>
> 2. Encrypt any protected image filename using that key. The check if user
> may access the file is done here, if he may not, no URL is generated.
>
> 3. On the image service, check for existence of the user object in the
> session, and decrypt the supplied filename using the key from the user
> object.
>
> 3. Read the image from the file system and stream it to the client.
>
> This should work for non-clustered systems, too.
>
> Is it better to use a tapestry service or a servlet for that kind of job?
>
> Regards
> Gregor
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
AW: AW: AW: Secure Files
Posted by Gregor Melhorn <g....@web.de>.
> Perhaps coda could do this but I had over 500gig of images but only 40gig
> drives on the web server. The method above allows this to happen
> transparently.
So basically you did just the same as coda would do - only you saved the
files to the database and took care of caching and updating yourself. Did I
get this right?
I found out I don't need separate image servers. Coda uses Multicast RCP for
updating files, so there is virtually no increase in network traffic if
using more servers, correct me if I'm wrong.
Basically this means I can use Coda as a file system, propagating changes
via Multicast and handle everything else, e.g. security, in tapestry as if
I'm using local files and don't have to care about clustering, without a
performance penalty compared to local access except when updating files.
Security would work like that (following some website I found about that):
1. Let the system generate a random key when a user logs on and store it in
the session (e.g in the user object).
2. Encrypt any protected image filename using that key. The check if user
may access the file is done here, if he may not, no URL is generated.
3. On the image service, check for existence of the user object in the
session, and decrypt the supplied filename using the key from the user
object.
3. Read the image from the file system and stream it to the client.
This should work for non-clustered systems, too.
Is it better to use a tapestry service or a servlet for that kind of job?
Regards
Gregor
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: AW: AW: Secure Files
Posted by Barry Books <bf...@mac.com>.
>I suppose with "key" you mean a unique image identifier (aka primary key),
>not something with encryption.
Yes I meant database key. I also just named the file from the key so the filename
for and image with a primary key of 1234 would be 1234.jpg
>It would be best if I could avoid requests to the database server from the
>image server, so there is only one request to the database for the
>construction of the tapestry page.
If your images never change then you would not need to hit the database to
determine the last modified time. My images could change.
>Problem with this is security - even with random filenames it would be
>possible to post them somewhere and send the links around to users without
>permission. In my last reply I explained how this could be avoided using an
>encrypted string for the key that contains the primary key of the image and
>an additional timestamp.
If the images are served from the cache thru a service you can apply any securtiy
you like. The images would not be directly accessible.
>Regarding image storage:
>Using coda the local caching is done automatically, and depending on
>configuration the file is either received from a central repository and
>cached if a user requests it or it is distributed to all servers on file
>upload (so every server always has an up-to-date copy on his hard drive).
>The synchronization happens transparently at disk IO level, so I don't have
>to care about it in my application. If a server goes down and misses some
>file uploads, it will receive them transparently from other servers after
>the images are requested.
Perhaps coda could do this but I had over 500gig of images but only 40gig drives
on the webserver. The method above allows this to happen transparently.
I also built some smarts into my image webservice. It could scale and rotate images
and since I had my images in the database I had multiple ones load balanced.
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
AW: AW: Secure Files
Posted by Gregor Melhorn <g....@web.de>.
I suppose with "key" you mean a unique image identifier (aka primary key),
not something with encryption.
It would be best if I could avoid requests to the database server from the
image server, so there is only one request to the database for the
construction of the tapestry page.
Problem with this is security - even with random filenames it would be
possible to post them somewhere and send the links around to users without
permission. In my last reply I explained how this could be avoided using an
encrypted string for the key that contains the primary key of the image and
an additional timestamp.
Regarding image storage:
Using coda the local caching is done automatically, and depending on
configuration the file is either received from a central repository and
cached if a user requests it or it is distributed to all servers on file
upload (so every server always has an up-to-date copy on his hard drive).
The synchronization happens transparently at disk IO level, so I don't have
to care about it in my application. If a server goes down and misses some
file uploads, it will receive them transparently from other servers after
the images are requested.
Regards
Gregor
-----Ursprüngliche Nachricht-----
Von: tapestry-user-return-18099-g.melhorn=web.de@jakarta.apache.org
[mailto:tapestry-user-return-18099-g.melhorn=web.de@jakarta.apache.org] Im
Auftrag von Barry Books
Gesendet: Sonntag, 13. März 2005 14:12
An: Tapestry users
Betreff: Re: AW: Secure Files
I built something similar to this. I stored the images in the database
but you don't have to.
Here's what I did
keep the key and the last update date of the photo in the database
build a webservice that returns a photo from the key. My service
returned the photo from the database but they
could just be in a filesytem behind a webserver
Build a page on the site that returns a photo from the key. This page
gets the last update from the database
checks it's local cache to see if it has the image. If it does just
send it, else get it from the webservice, cache it
then send it.
I also had a cron job that deleted cached images over 1 month old.
This gives you one place to keep images, the load on the image
database is light,
it's easy to deploy a new webserver and the site will mostly work even
if the image server is down
Barry
On Mar 12, 2005, at 10:58 AM, Gregor Melhorn wrote:
> Hi,
>
> I've got a similar problem:
>
> I am working on a photo community site, and the site should be able to
> handle around 10 000 concurrent users by clustering. Part of the images
> should only be visible to registered users.
>
> At present I'm using Spring, Hibernate 2.1.7, Tapestry 3.0 and Acegi
> Security, and I'm planning to upgrade to hibernate 3 and tapestry 3.1
> as
> soon as the new Spring version is out (I need Spring hibernate
> support).
> RDBMS will be MySQL NDB Cluster. I suppose I will deploy on tomcat,
> since I
> won't need EJB, and I'm planning to use OSCache anyway.
>
> The files won't be updated a lot, most will be uploaded once and
> afterwards
> only be viewed by other users. At most there will be around 300 GB of
> files,
> though 80 - 100 GB are far more realistic.
>
> I think I've got several choices on saving image files. One possibility
> would be saving the images to the database. Not a good plan I suppose,
> since
> MySQL Cluster is an in-memory-database and I'll most certainly run out
> of
> ram with this. Databases are not for saving large binary data...
>
> Another approach would be using a large harddrive in every webserver,
> and a
> network based filesystem as Coda, that automatically takes care of
> failover
> and updating the copies via the network.
>
> For serving the images I might use a tapestry service, that accesses
> the
> files via the local filesystem, or use a separate image server, that
> tapestry will only generate links. With the separate image server, I
> currently have no plans on how to implement security with this, though.
>
> Do you have any suggestions on the subject?
>
> By the way, this list is fantastic, it's really good to see so many
> people
> sharing their experience with others...
>
> Best regards
> Gregor Melhorn
>
>
>
> -----Ursprüngliche Nachricht---
> Von: tapestry-user-return-18077-g.melhorn=web.de@jakarta.apache.org
> [mailto:tapestry-user-return-18077-
> g.melhorn=web.de@jakarta.apache.org] Im
> Auftrag von Kent Tong
> Gesendet: Samstag, 12. März 2005 02:48
> An: tapestry-user@jakarta.apache.org
> Betreff: Re: Secure Files
>
> Stanczak Group <justin <at> stanczakgroup.com> writes:
>
>>
>> As part of my current app I have a place to upload files. These files
>> are saved to the file system and later accessed. These files should
>> only
>> be accessed by logged in users. So how would I go about securing these
>> in my Tapestry app. What I had in mind first was having all requests
>> for
>> files go thought a servlet that checks login status and then uses an
>> stream to send the file to the client, but I'm open to any
>> suggestions.
>
> This is fine, but in Tapestry we use a service instead of a servlet.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: AW: Secure Files
Posted by Barry Books <bf...@mac.com>.
I built something similar to this. I stored the images in the database
but you don't have to.
Here's what I did
keep the key and the last update date of the photo in the database
build a webservice that returns a photo from the key. My service
returned the photo from the database but they
could just be in a filesytem behind a webserver
Build a page on the site that returns a photo from the key. This page
gets the last update from the database
checks it's local cache to see if it has the image. If it does just
send it, else get it from the webservice, cache it
then send it.
I also had a cron job that deleted cached images over 1 month old.
This gives you one place to keep images, the load on the image
database is light,
it's easy to deploy a new webserver and the site will mostly work even
if the image server is down
Barry
On Mar 12, 2005, at 10:58 AM, Gregor Melhorn wrote:
> Hi,
>
> I've got a similar problem:
>
> I am working on a photo community site, and the site should be able to
> handle around 10 000 concurrent users by clustering. Part of the images
> should only be visible to registered users.
>
> At present I'm using Spring, Hibernate 2.1.7, Tapestry 3.0 and Acegi
> Security, and I'm planning to upgrade to hibernate 3 and tapestry 3.1
> as
> soon as the new Spring version is out (I need Spring hibernate
> support).
> RDBMS will be MySQL NDB Cluster. I suppose I will deploy on tomcat,
> since I
> won't need EJB, and I'm planning to use OSCache anyway.
>
> The files won't be updated a lot, most will be uploaded once and
> afterwards
> only be viewed by other users. At most there will be around 300 GB of
> files,
> though 80 - 100 GB are far more realistic.
>
> I think I've got several choices on saving image files. One possibility
> would be saving the images to the database. Not a good plan I suppose,
> since
> MySQL Cluster is an in-memory-database and I'll most certainly run out
> of
> ram with this. Databases are not for saving large binary data...
>
> Another approach would be using a large harddrive in every webserver,
> and a
> network based filesystem as Coda, that automatically takes care of
> failover
> and updating the copies via the network.
>
> For serving the images I might use a tapestry service, that accesses
> the
> files via the local filesystem, or use a separate image server, that
> tapestry will only generate links. With the separate image server, I
> currently have no plans on how to implement security with this, though.
>
> Do you have any suggestions on the subject?
>
> By the way, this list is fantastic, it's really good to see so many
> people
> sharing their experience with others...
>
> Best regards
> Gregor Melhorn
>
>
>
> -----Ursprüngliche Nachricht---
> Von: tapestry-user-return-18077-g.melhorn=web.de@jakarta.apache.org
> [mailto:tapestry-user-return-18077-
> g.melhorn=web.de@jakarta.apache.org] Im
> Auftrag von Kent Tong
> Gesendet: Samstag, 12. März 2005 02:48
> An: tapestry-user@jakarta.apache.org
> Betreff: Re: Secure Files
>
> Stanczak Group <justin <at> stanczakgroup.com> writes:
>
>>
>> As part of my current app I have a place to upload files. These files
>> are saved to the file system and later accessed. These files should
>> only
>> be accessed by logged in users. So how would I go about securing these
>> in my Tapestry app. What I had in mind first was having all requests
>> for
>> files go thought a servlet that checks login status and then uses an
>> stream to send the file to the client, but I'm open to any
>> suggestions.
>
> This is fine, but in Tapestry we use a service instead of a servlet.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
AW: Secure Files
Posted by Gregor Melhorn <g....@web.de>.
Hi,
I've got a similar problem:
I am working on a photo community site, and the site should be able to
handle around 10 000 concurrent users by clustering. Part of the images
should only be visible to registered users.
At present I'm using Spring, Hibernate 2.1.7, Tapestry 3.0 and Acegi
Security, and I'm planning to upgrade to hibernate 3 and tapestry 3.1 as
soon as the new Spring version is out (I need Spring hibernate support).
RDBMS will be MySQL NDB Cluster. I suppose I will deploy on tomcat, since I
won't need EJB, and I'm planning to use OSCache anyway.
The files won't be updated a lot, most will be uploaded once and afterwards
only be viewed by other users. At most there will be around 300 GB of files,
though 80 - 100 GB are far more realistic.
I think I've got several choices on saving image files. One possibility
would be saving the images to the database. Not a good plan I suppose, since
MySQL Cluster is an in-memory-database and I'll most certainly run out of
ram with this. Databases are not for saving large binary data...
Another approach would be using a large harddrive in every webserver, and a
network based filesystem as Coda, that automatically takes care of failover
and updating the copies via the network.
For serving the images I might use a tapestry service, that accesses the
files via the local filesystem, or use a separate image server, that
tapestry will only generate links. With the separate image server, I
currently have no plans on how to implement security with this, though.
Do you have any suggestions on the subject?
By the way, this list is fantastic, it's really good to see so many people
sharing their experience with others...
Best regards
Gregor Melhorn
-----Ursprüngliche Nachricht---
Von: tapestry-user-return-18077-g.melhorn=web.de@jakarta.apache.org
[mailto:tapestry-user-return-18077-g.melhorn=web.de@jakarta.apache.org] Im
Auftrag von Kent Tong
Gesendet: Samstag, 12. März 2005 02:48
An: tapestry-user@jakarta.apache.org
Betreff: Re: Secure Files
Stanczak Group <justin <at> stanczakgroup.com> writes:
>
> As part of my current app I have a place to upload files. These files
> are saved to the file system and later accessed. These files should only
> be accessed by logged in users. So how would I go about securing these
> in my Tapestry app. What I had in mind first was having all requests for
> files go thought a servlet that checks login status and then uses an
> stream to send the file to the client, but I'm open to any suggestions.
This is fine, but in Tapestry we use a service instead of a servlet.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Secure Files
Posted by Kent Tong <ke...@cpttm.org.mo>.
Stanczak Group <justin <at> stanczakgroup.com> writes:
>
> As part of my current app I have a place to upload files. These files
> are saved to the file system and later accessed. These files should only
> be accessed by logged in users. So how would I go about securing these
> in my Tapestry app. What I had in mind first was having all requests for
> files go thought a servlet that checks login status and then uses an
> stream to send the file to the client, but I'm open to any suggestions.
This is fine, but in Tapestry we use a service instead of a servlet.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Secure Files
Posted by Daniel Serodio <ds...@mandic.com.br>.
Stanczak Group wrote:
> As part of my current app I have a place to upload files. These files
> are saved to the file system and later accessed. These files should
> only be accessed by logged in users. So how would I go about securing
> these in my Tapestry app. What I had in mind first was having all
> requests for files go thought a servlet that checks login status and
> then uses an stream to send the file to the client, but I'm open to
> any suggestions.
>
AFAIK, the best way to handle authentication is thru a Filter, not a
Servlet.
[]'s
Daniel Serodio
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org