Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #28477 > unrolled thread

application server, just without the "web" part...

Back to article view | Back to comp.lang.java.programmer

Contents

  application server, just without the "web" part... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-05-14 19:16 +0000
    Re: application server, just without the "web" part... markspace <markspace@nospam.nospam> - 2014-05-14 13:23 -0700
    Re: application server, just without the "web" part... leif.roar@invalid.com (Leif Roar Moldskred) - 2014-05-14 16:57 -0500
      Re: application server, just without the "web" part... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-05-15 14:16 +0000
    Re: application server, just without the "web" part... Arne Vajhøj <arne@vajhoej.dk> - 2014-05-14 19:46 -0400
      Re: application server, just without the "web" part... Joerg Meier <joergmmeier@arcor.de> - 2014-05-15 12:25 +0200
        Re: application server, just without the "web" part... Arne Vajhøj <arne@vajhoej.dk> - 2014-05-16 21:06 -0400
      Re: application server, just without the "web" part... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-05-15 14:32 +0000
        Re: application server, just without the "web" part... Arne Vajhøj <arne@vajhoej.dk> - 2014-05-16 21:10 -0400
          Re: application server, just without the "web" part... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-05-17 09:46 +0000
            Re: application server, just without the "web" part... Jeff Higgins <jeff@invalid.invalid> - 2014-05-17 07:42 -0400
              Re: application server, just without the "web" part... Jeff Higgins <jeff@invalid.invalid> - 2014-05-17 08:52 -0400
                Re: application server, just without the "web" part... Jeff Higgins <jeff@invalid.invalid> - 2014-05-17 09:07 -0400
                  Re: application server, just without the "web" part... Jeff Higgins <jeff@invalid.invalid> - 2014-05-17 09:12 -0400
                    Re: application server, just without the "web" part... Luuk <luuk@invalid.lan> - 2014-05-17 15:35 +0200
                      Re: application server, just without the "web" part... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-06-16 18:21 +0000
          Re: application server, just without the "web" part... "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-05-17 10:49 +0100
    Re: application server, just without the "web" part... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-05-15 14:10 +0000
    Re: application server, just without the "web" part... "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-05-17 11:00 +0100
      Re: application server, just without the "web" part... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-09-03 17:51 +0000
        Re: application server, just without the "web" part... Martin Gregorie <martin@address-in-sig.invalid> - 2014-09-03 18:29 +0000
          Re: application server, just without the "web" part... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-09-03 18:43 +0000
          Re: application server, just without the "web" part... Martin Gregorie <martin@address-in-sig.invalid> - 2014-09-03 19:43 +0000
            Re: application server, just without the "web" part... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-09-04 07:36 +0000
              Re: application server, just without the "web" part... Martin Gregorie <martin@address-in-sig.invalid> - 2014-09-04 12:13 +0000
                Re: application server, just without the "web" part... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-09-05 00:43 +0000
                  Re: application server, just without the "web" part... Martin Gregorie <martin@address-in-sig.invalid> - 2014-09-05 09:14 +0000
                    Re: application server, just without the "web" part... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-09-05 10:43 +0000
                      Re: application server, just without the "web" part... Martin Gregorie <martin@address-in-sig.invalid> - 2014-09-05 21:45 +0000
    Re: application server, just without the "web" part... Roedy Green <see_website@mindprod.com.invalid> - 2014-06-20 08:09 -0700
    Re: application server, just without the "web" part... Roedy Green <see_website@mindprod.com.invalid> - 2014-06-20 08:13 -0700
      Re: application server, just without the "web" part... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-09-03 17:33 +0000

Page 2 of 2 — ← Prev page 1 [2]

#29895

On Wed, 03 Sep 2014 17:51:45 +0000, Andreas Leitgeb wrote:

> Meanwhile that's the remaining part of my problem. The authorization
> should not be part of the protocol, but some local "challenge", that
> only a particular user on the same machine can do. E.g. write to an
> appropriately set up named pipe or unix domain socket.  Unfortunately,
> Java doesn't seem to support unix domain sockets without JNI, and named
> pipes have their own bag of downsides.  See new thread "java unix domain
> sockets ..."
>
I think you can do what you need with bog standard Java Sockets. Assuming 
that this program will be listening for incoming connections on a 
ServerSocket, if your first action after ServerSocket.accept() returns a 
Socket, is to call Socket.getInetAddress(). You can easily check whether 
the InetAddress it returns is a local loopback connection or not: if it 
is on the local loopback, the IP address will be 127.0.0.1 or the IPV6 
equivalent.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#29896

Martin Gregorie <martin@address-in-sig.invalid> wrote:
> On Wed, 03 Sep 2014 17:51:45 +0000, Andreas Leitgeb wrote:
>
>> Meanwhile that's the remaining part of my problem. The authorization
>> should not be part of the protocol, but some local "challenge", that
>> only a particular user on the same machine can do. E.g. write to an
>> appropriately set up named pipe or unix domain socket.  Unfortunately,
>> Java doesn't seem to support unix domain sockets without JNI, and named
>> pipes have their own bag of downsides.  See new thread "java unix domain
>> sockets ..."
>>
> I think you can do what you need with bog standard Java Sockets. Assuming 
> that this program will be listening for incoming connections on a 
> ServerSocket, if your first action after ServerSocket.accept() returns a 
> Socket, is to call Socket.getInetAddress(). You can easily check whether 
> the InetAddress it returns is a local loopback connection or not: if it 
> is on the local loopback, the IP address will be 127.0.0.1 or the IPV6 
> equivalent.

Any local user can make a connection to a localhost inet socket, and the peer
will then always be localhost as well.

But not all users on a particular machine are equal for the sake of my server
(running on that same machine, started by user "foo" for his own use).
I want: 'Local user "foo" shall pass, local user "bar" shall not pass.'

[toc] | [prev] | [next] | [standalone]

#29897

On Wed, 03 Sep 2014 18:29:57 +0000, Martin Gregorie wrote:

> On Wed, 03 Sep 2014 17:51:45 +0000, Andreas Leitgeb wrote:
> 
>> Meanwhile that's the remaining part of my problem. The authorization
>> should not be part of the protocol, but some local "challenge", that
>> only a particular user on the same machine can do. E.g. write to an
>> appropriately set up named pipe or unix domain socket.  Unfortunately,
>> Java doesn't seem to support unix domain sockets without JNI, and named
>> pipes have their own bag of downsides.  See new thread "java unix
>> domain sockets ..."
>>
> I think you can do what you need with bog standard Java Sockets.
> Assuming that this program will be listening for incoming connections on
> a ServerSocket, if your first action after ServerSocket.accept() returns
> a Socket, is to call Socket.getInetAddress(). You can easily check
> whether the InetAddress it returns is a local loopback connection or
> not: if it is on the local loopback, the IP address will be 127.0.0.1 or
> the IPV6 equivalent.

I missed seeing the restriction to specific users on the local box. My 
bad. Would requiring the authorised users to belong to a specific group 
help solve the problem?


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#29898

Martin Gregorie <martin@address-in-sig.invalid> wrote:
> On Wed, 03 Sep 2014 18:29:57 +0000, Martin Gregorie wrote:
>> On Wed, 03 Sep 2014 17:51:45 +0000, Andreas Leitgeb wrote:
>>> Meanwhile that's the remaining part of my problem. The authorization
>>> should not be part of the protocol, but some local "challenge", that
>>> only a particular user on the same machine can do. E.g. write to an
>>> appropriately set up named pipe or unix domain socket.  Unfortunately,
>>> Java doesn't seem to support unix domain sockets without JNI, and named
>>> pipes have their own bag of downsides.  See new thread "java unix
>>> domain sockets ..."
>> I think you can do what you need with bog standard Java Sockets.
>> Assuming that this program will be listening for incoming connections on
>> a ServerSocket, if your first action after ServerSocket.accept() returns
>> a Socket, is to call Socket.getInetAddress(). You can easily check
>> whether the InetAddress it returns is a local loopback connection or
>> not: if it is on the local loopback, the IP address will be 127.0.0.1 or
>> the IPV6 equivalent.
> I missed seeing the restriction to specific users on the local box. My 
> bad. Would requiring the authorised users to belong to a specific group 
> help solve the problem?

I'd be very curious about a mechanism that could be used to restrict the
connecting user's group (even if that same mechanism couldn't also be used
to restrict the user)

Admittedly, not so much for the task at hand, but for general learning...

[toc] | [prev] | [next] | [standalone]

#29905

On Thu, 04 Sep 2014 07:36:22 +0000, Andreas Leitgeb wrote:

> Martin Gregorie <martin@address-in-sig.invalid> wrote:
>> On Wed, 03 Sep 2014 18:29:57 +0000, Martin Gregorie wrote:
>>> On Wed, 03 Sep 2014 17:51:45 +0000, Andreas Leitgeb wrote:
>>>> Meanwhile that's the remaining part of my problem. The authorization
>>>> should not be part of the protocol, but some local "challenge", that
>>>> only a particular user on the same machine can do. E.g. write to an
>>>> appropriately set up named pipe or unix domain socket. 
>>>> Unfortunately, Java doesn't seem to support unix domain sockets
>>>> without JNI, and named pipes have their own bag of downsides.  See
>>>> new thread "java unix domain sockets ..."
>>> I think you can do what you need with bog standard Java Sockets.
>>> Assuming that this program will be listening for incoming connections
>>> on a ServerSocket, if your first action after ServerSocket.accept()
>>> returns a Socket, is to call Socket.getInetAddress(). You can easily
>>> check whether the InetAddress it returns is a local loopback
>>> connection or not: if it is on the local loopback, the IP address will
>>> be 127.0.0.1 or the IPV6 equivalent.
>> I missed seeing the restriction to specific users on the local box. My
>> bad. Would requiring the authorised users to belong to a specific group
>> help solve the problem?
> 
> I'd be very curious about a mechanism that could be used to restrict the
> connecting user's group (even if that same mechanism couldn't also be
> used to restrict the user)
> 
> Admittedly, not so much for the task at hand, but for general
> learning...

AFAIK you can't do it in pure Java, but the possibilities are:

- run the groups utility via ProcessBuilder and examine the list of
  groups it returns. This is a Free Software Foundation utility program
  that  writes a space-delimited list of groups to stdout. Using it may
  be the easiest way to check group membership: obviously, once the group
  list has been retrieved it can be scanned by either client or server to
  see whether the caller is a member of the required group. 

- call getgrouplist() via JNI. getgrouplist() is a nonstandard function,
  but is available in Linux and (it says) most BSD versions. The manpage
  has an example utility that calls it.

- have the process call getgroups() via JNI, though this would only
  return the group ID of supplementary groups the process is a member of.

I hope this is useful info.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#29914

Martin Gregorie <martin@address-in-sig.invalid> wrote:
> On Thu, 04 Sep 2014 07:36:22 +0000, Andreas Leitgeb wrote:
>> Martin Gregorie <martin@address-in-sig.invalid> wrote:
>>> I missed seeing the restriction to specific users on the local box. My
>>> bad. Would requiring the authorised users to belong to a specific group
>>> help solve the problem?
>> I'd be very curious about a mechanism that could be used to restrict the
>> connecting user's group (even if that same mechanism couldn't also be
>> used to restrict the user)

> - run the groups utility via ProcessBuilder and examine the list of
>   groups it returns.

Well, I think that missed the point. The Java server has no point in
looking up its own user's list of groups.  If anything, it would need
the *connecting* guy's groups...

> I hope this is useful info.

Well, maybe for someone with a different problem ;-)

[toc] | [prev] | [next] | [standalone]

#29919

On Fri, 05 Sep 2014 00:43:50 +0000, Andreas Leitgeb wrote:

> Well, I think that missed the point. The Java server has no point in
> looking up its own user's list of groups.  If anything, it would need
> the *connecting* guy's groups...
>
What makes you think I suggested running that on the server? 

Its true I said that the list returned by 'groups' could be *scanned* by 
either the client or server but I never said nor implied that 'groups' 
should be run anywhere except on the client.
 


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#29920

Martin Gregorie <martin@address-in-sig.invalid> wrote:
> On Fri, 05 Sep 2014 00:43:50 +0000, Andreas Leitgeb wrote:
>> Well, I think that missed the point. The Java server has no point in
>> looking up its own user's list of groups.  If anything, it would need
>> the *connecting* guy's groups...
> What makes you think I suggested running that on the server? 

Because the thread was about having non-java clients connect to a java
server for certain tasks to the effect of not suffering from JVM-startup
times for each single task.  Now you showed how to obtain groups list in
Java. No big deal, but that's just what made me think the suggestion was
for the server. :-)

Some previous comment of yours about group-based *connection security* had
made me curious, but as it seems it's nothing different from what has been
brought up already: Have the client present some "secret" (although the
group-list wouldn't really qualify as a secret) over the connection.
Something I wanted (and succeeded) doing *without*.

This topic is solved, meanwhile.  I use named pipes now, and I got this
part working like a charm.  Short task now take about a few milliseconds
(including the non-java client) and even longer tasks benefit noticeably
from already warmed-up hotspot.
Compare that to 1-3 seconds of JVM startup :-)

[toc] | [prev] | [next] | [standalone]

#29923

On Fri, 05 Sep 2014 10:43:00 +0000, Andreas Leitgeb wrote:

I wasn't meaning to push the use of a group as a secret - more as 
something an admin could to easily grant or withdraw permission to use a 
service, and not that its one that can easily be inplemented throughout a 
cluster or a LAN with little overhead cost in either administration or 
client start-up time. Just a thought.

> This topic is solved, meanwhile.  I use named pipes now, and I got this
> part working like a charm.  Short task now take about a few milliseconds
> (including the non-java client) and even longer tasks benefit noticeably
> from already warmed-up hotspot.
> Compare that to 1-3 seconds of JVM startup :-)
>
Sounds good to me.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#28794

On Wed, 14 May 2014 19:16:13 +0000 (UTC), Andreas Leitgeb
<avl@auth.logic.tuwien.ac.at> wrote, quoted or indirectly quoted
someone who said :

>
>Does something like this already exist?

See http://mindprod.com/jgloss/jenkins.html

This a specialised version of what you want for running build scripts
and running unit tests.

Perhaps it does what you want too.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Software gets slower faster than hardware gets faster. 
~ Niklaus Wirth (born: 1934-02-15 age: 80) Wirth's Law

[toc] | [prev] | [next] | [standalone]

#28795

On Wed, 14 May 2014 19:16:13 +0000 (UTC), Andreas Leitgeb
<avl@auth.logic.tuwien.ac.at> wrote, quoted or indirectly quoted
someone who said :

>Essentially my application is a couple of separate command-line
>utilities, called from users with shell-access (or from unix
>shell scripts).
>
>Startup-time still isn't exactly Java's strong point, and often
>enough in my situation the startup time is by far the "longest
>pole in the tent".
>Adding option -Xshareclasses improved things, but not enough.
>
>I'd like to consider some kind of application server, that would 
>run the actual java-code of any number of jobs (of one user) in one
>jvm, and with an "interface", that would only allow that one user to
>start new jobs.
>
>Does something like this already exist?
>
>PS: the actual jobs need to be in Java, because they need certain
>  Java-libraries for their work. The server would know all relevant
>  classes beforehand.

If the thing that triggers them is written in Java, you still have to
fire up the JVM.  To get around that you could use Excelsion jet which
creates native executables that start quickly.

You generate C code for the triggers and compile it. It could send a
TCP-IP request to your server code.

See http://mindprod.com/products1.html#ECHOSERVER for an absolutely
bare bones server you might flesh out.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Software gets slower faster than hardware gets faster. 
~ Niklaus Wirth (born: 1934-02-15 age: 80) Wirth's Law

[toc] | [prev] | [next] | [standalone]

#29892

Roedy Green <see_website@mindprod.com.invalid> wrote:
> On Wed, 14 May 2014 19:16:13 +0000 (UTC), Andreas Leitgeb wrote
>>Startup-time still isn't exactly Java's strong point, and often
>>enough in my situation the startup time is by far the "longest
>>pole in the tent".
>
> To get around that you could use Excelsion jet which
> creates native executables that start quickly.

Unfortunately not available for the platforms I need...
(Solaris & AIX)

But thanks, anyway

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web