[jira] Commented: (DIRMINA-539) NioDatagramConnector doesn't takes the TrafficClass value set to his DatagramSessionConfig
[ https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12648934#action_12648934 ] Emmanuel Lecharny commented on DIRMINA-539: --- The question is : do we really need this method in 2.0 (ie, isSetTrafficClassAvailable). The main problem is that we need an open socket in order to check that, and we have to set the traffic class, and reset it, to be sure that it's possible. As the Traffic Class is absolutely not guaranteed to be used by the underlying network layer, I think it's a lot of effort for a small improvement. Now, this can be discussed. I understand that, from the user POV, masking all this complexity is good, but when a user tries to manipulate such advanced features, I think that it should be explicit. NioDatagramConnector doesn't takes the TrafficClass value set to his DatagramSessionConfig --- Key: DIRMINA-539 URL: https://issues.apache.org/jira/browse/DIRMINA-539 Project: MINA Issue Type: Bug Affects Versions: 2.0.0-M1 Environment: WinXP, RHEL5 (probably not important) Reporter: martin krivosik Assignee: Emmanuel Lecharny Fix For: 2.0.0-M4 Original Estimate: 0.33h Remaining Estimate: 0.33h client sending datagrams without taking care to the trafficClas set in the config, so the ToS byte is not set in the packet sent from client. client code: NioDatagramAcceptor acceptor = new NioDatagramAcceptor(); DatagramSessionConfig dcfg = ((NioDatagramAcceptor)acceptor).getSessionConfig(); dcfg.setTrafficClass(tosByte); InetSocketAddress bindAddrPort = new InetSocketAddress(originatingIP, port); acceptor.bind(bindAddrPort); - connecting to another computer with NioDatagramConnector. for me it looks like in the newHandle method of NioDatagramConnector is not cared about TrafficClass (like it is done in NioDatagramAcceptor.open()) The server part with the accceptor is OK and the correct ToS byte is set in the packet. (the same problem may be in the socket, i have to check it) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-23) New transport type: non-NIO sockets
[ https://issues.apache.org/jira/browse/DIRMINA-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12648935#action_12648935 ] Emmanuel Lecharny commented on DIRMINA-23: -- Let's keep it open, with no fix version. New transport type: non-NIO sockets --- Key: DIRMINA-23 URL: https://issues.apache.org/jira/browse/DIRMINA-23 Project: MINA Issue Type: New Feature Components: Core Affects Versions: 0.7.0, 0.8.0 Reporter: Trustin Lee Current NIO implementation doesn't outperform non-NIO sockets, and doesn't support multicasting. We could complement this gap by adding transport type support for non-NIO sockets. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-637) SSLEngine output buffer seems to be too small
[
https://issues.apache.org/jira/browse/DIRMINA-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRMINA-637:
--
Fix Version/s: 1.1.8
We should check if it also affects 2.0.0
SSLEngine output buffer seems to be too small
-
Key: DIRMINA-637
URL: https://issues.apache.org/jira/browse/DIRMINA-637
Project: MINA
Issue Type: Bug
Components: Filter
Affects Versions: 1.1.1, 1.1.7
Reporter: Dan Mihai Dumitriu
Assignee: Emmanuel Lecharny
Fix For: 1.1.8
the code below is in SSLHandler.java. it makes the assumption that the size
of the output will never be larger than 2x the size of the input. that
assumption appears to not hold up. It looks like this code has been fixed in
trunk, but not in 1.1.7. we only see an error for VERY specific content,
i.e. almost never.
public void encrypt(ByteBuffer src) throws SSLException {
if (!initialHandshakeComplete) {
throw new IllegalStateException();
}
// The data buffer is (must be) empty, we can reuse the entire
// buffer.
outNetBuffer.clear();
// Loop until there is no more data in src
while (src.hasRemaining()) {
if (src.remaining() ((outNetBuffer.capacity() - outNetBuffer
.position()) / 2)) {
// We have to expand outNetBuffer
// Note: there is no way to know the exact size required, but
enrypted data
// shouln't need to be larger than twice the source data size?
outNetBuffer = SSLByteBufferPool.expandBuffer(outNetBuffer,
src
.capacity() * 2);
if (SessionLog.isDebugEnabled(session)) {
SessionLog.debug(session, expanded outNetBuffer:
+ outNetBuffer);
}
}
SSLEngineResult result = sslEngine.wrap(src, outNetBuffer);
if (SessionLog.isDebugEnabled(session)) {
SessionLog.debug(session, Wrap res: + result);
}
if (result.getStatus() == SSLEngineResult.Status.OK) {
if (result.getHandshakeStatus() ==
SSLEngineResult.HandshakeStatus.NEED_TASK) {
doTasks();
}
} else {
throw new SSLException(SSLEngine error during encrypt:
+ result.getStatus() + src: + src
+ outNetBuffer: + outNetBuffer);
}
}
outNetBuffer.flip();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DIRMINA-637) SSLEngine output buffer seems to be too small
[
https://issues.apache.org/jira/browse/DIRMINA-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny reassigned DIRMINA-637:
-
Assignee: Emmanuel Lecharny
SSLEngine output buffer seems to be too small
-
Key: DIRMINA-637
URL: https://issues.apache.org/jira/browse/DIRMINA-637
Project: MINA
Issue Type: Bug
Components: Filter
Affects Versions: 1.1.1, 1.1.7
Reporter: Dan Mihai Dumitriu
Assignee: Emmanuel Lecharny
Fix For: 1.1.8
the code below is in SSLHandler.java. it makes the assumption that the size
of the output will never be larger than 2x the size of the input. that
assumption appears to not hold up. It looks like this code has been fixed in
trunk, but not in 1.1.7. we only see an error for VERY specific content,
i.e. almost never.
public void encrypt(ByteBuffer src) throws SSLException {
if (!initialHandshakeComplete) {
throw new IllegalStateException();
}
// The data buffer is (must be) empty, we can reuse the entire
// buffer.
outNetBuffer.clear();
// Loop until there is no more data in src
while (src.hasRemaining()) {
if (src.remaining() ((outNetBuffer.capacity() - outNetBuffer
.position()) / 2)) {
// We have to expand outNetBuffer
// Note: there is no way to know the exact size required, but
enrypted data
// shouln't need to be larger than twice the source data size?
outNetBuffer = SSLByteBufferPool.expandBuffer(outNetBuffer,
src
.capacity() * 2);
if (SessionLog.isDebugEnabled(session)) {
SessionLog.debug(session, expanded outNetBuffer:
+ outNetBuffer);
}
}
SSLEngineResult result = sslEngine.wrap(src, outNetBuffer);
if (SessionLog.isDebugEnabled(session)) {
SessionLog.debug(session, Wrap res: + result);
}
if (result.getStatus() == SSLEngineResult.Status.OK) {
if (result.getHandshakeStatus() ==
SSLEngineResult.HandshakeStatus.NEED_TASK) {
doTasks();
}
} else {
throw new SSLException(SSLEngine error during encrypt:
+ result.getStatus() + src: + src
+ outNetBuffer: + outNetBuffer);
}
}
outNetBuffer.flip();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [PROPOSAL] Create a MINA subproject to implement a SSH server based on Mina
I guess the next step is to start a formal vote about that, right ? As I've been the only committer on the project, I don't think a software grant would be needed for that. On Thu, Nov 13, 2008 at 3:07 PM, Guillaume Nodet [EMAIL PROTECTED] wrote: A few weeks ago, I've started a small project at googlecode to implement an SSH server in Java based on Mina. You'll find some background at http://gnodet.blogspot.com/ The project is still in its early stage and require a lot more work to be fully usable, but I've been doing some tests and the basic SSH protocol itself is implemented. The project is available at http://code.google.com/p/sshd/ My thinking is that it would be a good candidate to become a subproject of Mina (along with ftpserver and asyncweb), so i'm starting this discussion to gauge the interest of the MINA TLP to host such a subproject. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Commented: (DIRMINA-637) SSLEngine output buffer seems to be too small
[
https://issues.apache.org/jira/browse/DIRMINA-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12649005#action_12649005
]
Emmanuel Lecharny commented on DIRMINA-637:
---
Ok, so we are safe in 2.0 :) That's a good news !
SSLEngine output buffer seems to be too small
-
Key: DIRMINA-637
URL: https://issues.apache.org/jira/browse/DIRMINA-637
Project: MINA
Issue Type: Bug
Components: Filter
Affects Versions: 1.1.1, 1.1.7
Reporter: Dan Mihai Dumitriu
Assignee: Emmanuel Lecharny
Fix For: 1.1.8
the code below is in SSLHandler.java. it makes the assumption that the size
of the output will never be larger than 2x the size of the input. that
assumption appears to not hold up. It looks like this code has been fixed in
trunk, but not in 1.1.7. we only see an error for VERY specific content,
i.e. almost never.
public void encrypt(ByteBuffer src) throws SSLException {
if (!initialHandshakeComplete) {
throw new IllegalStateException();
}
// The data buffer is (must be) empty, we can reuse the entire
// buffer.
outNetBuffer.clear();
// Loop until there is no more data in src
while (src.hasRemaining()) {
if (src.remaining() ((outNetBuffer.capacity() - outNetBuffer
.position()) / 2)) {
// We have to expand outNetBuffer
// Note: there is no way to know the exact size required, but
enrypted data
// shouln't need to be larger than twice the source data size?
outNetBuffer = SSLByteBufferPool.expandBuffer(outNetBuffer,
src
.capacity() * 2);
if (SessionLog.isDebugEnabled(session)) {
SessionLog.debug(session, expanded outNetBuffer:
+ outNetBuffer);
}
}
SSLEngineResult result = sslEngine.wrap(src, outNetBuffer);
if (SessionLog.isDebugEnabled(session)) {
SessionLog.debug(session, Wrap res: + result);
}
if (result.getStatus() == SSLEngineResult.Status.OK) {
if (result.getHandshakeStatus() ==
SSLEngineResult.HandshakeStatus.NEED_TASK) {
doTasks();
}
} else {
throw new SSLException(SSLEngine error during encrypt:
+ result.getStatus() + src: + src
+ outNetBuffer: + outNetBuffer);
}
}
outNetBuffer.flip();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-637) SSLEngine output buffer seems to be too small
[
https://issues.apache.org/jira/browse/DIRMINA-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12649003#action_12649003
]
Dan Mihai Dumitriu commented on DIRMINA-637:
I don't believe that it does. The 2.0.0 code doubles the output buffer and
tries again if there is overflow.
SSLEngine output buffer seems to be too small
-
Key: DIRMINA-637
URL: https://issues.apache.org/jira/browse/DIRMINA-637
Project: MINA
Issue Type: Bug
Components: Filter
Affects Versions: 1.1.1, 1.1.7
Reporter: Dan Mihai Dumitriu
Assignee: Emmanuel Lecharny
Fix For: 1.1.8
the code below is in SSLHandler.java. it makes the assumption that the size
of the output will never be larger than 2x the size of the input. that
assumption appears to not hold up. It looks like this code has been fixed in
trunk, but not in 1.1.7. we only see an error for VERY specific content,
i.e. almost never.
public void encrypt(ByteBuffer src) throws SSLException {
if (!initialHandshakeComplete) {
throw new IllegalStateException();
}
// The data buffer is (must be) empty, we can reuse the entire
// buffer.
outNetBuffer.clear();
// Loop until there is no more data in src
while (src.hasRemaining()) {
if (src.remaining() ((outNetBuffer.capacity() - outNetBuffer
.position()) / 2)) {
// We have to expand outNetBuffer
// Note: there is no way to know the exact size required, but
enrypted data
// shouln't need to be larger than twice the source data size?
outNetBuffer = SSLByteBufferPool.expandBuffer(outNetBuffer,
src
.capacity() * 2);
if (SessionLog.isDebugEnabled(session)) {
SessionLog.debug(session, expanded outNetBuffer:
+ outNetBuffer);
}
}
SSLEngineResult result = sslEngine.wrap(src, outNetBuffer);
if (SessionLog.isDebugEnabled(session)) {
SessionLog.debug(session, Wrap res: + result);
}
if (result.getStatus() == SSLEngineResult.Status.OK) {
if (result.getHandshakeStatus() ==
SSLEngineResult.HandshakeStatus.NEED_TASK) {
doTasks();
}
} else {
throw new SSLException(SSLEngine error during encrypt:
+ result.getStatus() + src: + src
+ outNetBuffer: + outNetBuffer);
}
}
outNetBuffer.flip();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
About DefaultDatagramSessionConfig and DefaultSocketSessionConfig
Hi, there are a few problematic JIRA's related to the way those classes are implemented. Mainly people are complaining on Vista and also when MINA is used inside an applet, that it creates some ServerSocket and a Socket in order to define the default socket/datagram configuration on the system those applications are running on. Despite the fact that this test is done in order to provide a set of default values, it does more harm than it helps, as it's pretty intrusive. We have to find a better way to do that, or may be remove this feature from the framework. Last, not least, it does not deal with ServerSocket options, which are a sub-set of the Socket options (and I'm not sure MINA 2 covers all the socket options anyway). Here are the options supported by Socket/ServerSocket/Datagram on java 1.5 : Datagram SO_BROADCAST SO_RCVBUF SO_REUSEADDR SO_SNDBUF SO_TIMEOUT IP_TOS Socket -- SO_KEEPALIVE SO_OOBINLINE SO_RCVBUF SO_REUSEADDR SO_SNDBUF SO_LINGER SO_TIMEOUT TCP_NODELAY IP_TOS ServerSocket SO_RCVBUF SO_REUSEADDR SO_TIMEOUT As we need an existing socket to check this socket capability, the current framework tries to create such a socket/datagram, and check for the default options, setting some booleans accordingly. We can do it the same way but on the first created socket, and stores the result in static parameters. We just have to define a single boolean (configInitialized) which will be turned to true as soon as we have created the first socket/datagram/serverSocket. Of course, this part must be synchronized. Anyone has a better idea ? -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
[jira] Commented: (DIRMINA-637) SSLEngine output buffer seems to be too small
[
https://issues.apache.org/jira/browse/DIRMINA-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12649042#action_12649042
]
Dan Mihai Dumitriu commented on DIRMINA-637:
To fix our immediate problem, I adapted the code from 2.0.0, as shown below.
Maybe it would be good to make the initial capacity larger than just
src.remaining(), so that it doesn't overflow everytime.
public void encrypt(ByteBuffer src) throws SSLException {
if (!handshakeComplete) {
throw new IllegalStateException();
}
// The data buffer is (must be) empty, we can reuse the entire
// buffer.
outNetBuffer.clear();
int capacity = Math.max(
src.remaining(),
sslEngine.getSession().getPacketBufferSize());
outNetBuffer = SSLByteBufferPool.expandBuffer(outNetBuffer, capacity);
// Loop until there is no more data in src
while (src.hasRemaining()) {
SSLEngineResult result = sslEngine.wrap(src, outNetBuffer);
if (result.getStatus() == SSLEngineResult.Status.OK) {
if (result.getHandshakeStatus() ==
SSLEngineResult.HandshakeStatus.NEED_TASK) {
doTasks();
}
} else if (result.getStatus() ==
SSLEngineResult.Status.BUFFER_OVERFLOW) {
outNetBuffer = SSLByteBufferPool.expandBuffer(outNetBuffer,
outNetBuffer.capacity() * 2);
} else {
throw new SSLException(SSLEngine error during encrypt:
+ result.getStatus() + src: + src
+ outNetBuffer: + outNetBuffer);
}
}
outNetBuffer.flip();
}
SSLEngine output buffer seems to be too small
-
Key: DIRMINA-637
URL: https://issues.apache.org/jira/browse/DIRMINA-637
Project: MINA
Issue Type: Bug
Components: Filter
Affects Versions: 1.1.1, 1.1.7
Reporter: Dan Mihai Dumitriu
Assignee: Emmanuel Lecharny
Fix For: 1.1.8
the code below is in SSLHandler.java. it makes the assumption that the size
of the output will never be larger than 2x the size of the input. that
assumption appears to not hold up. It looks like this code has been fixed in
trunk, but not in 1.1.7. we only see an error for VERY specific content,
i.e. almost never.
public void encrypt(ByteBuffer src) throws SSLException {
if (!initialHandshakeComplete) {
throw new IllegalStateException();
}
// The data buffer is (must be) empty, we can reuse the entire
// buffer.
outNetBuffer.clear();
// Loop until there is no more data in src
while (src.hasRemaining()) {
if (src.remaining() ((outNetBuffer.capacity() - outNetBuffer
.position()) / 2)) {
// We have to expand outNetBuffer
// Note: there is no way to know the exact size required, but
enrypted data
// shouln't need to be larger than twice the source data size?
outNetBuffer = SSLByteBufferPool.expandBuffer(outNetBuffer,
src
.capacity() * 2);
if (SessionLog.isDebugEnabled(session)) {
SessionLog.debug(session, expanded outNetBuffer:
+ outNetBuffer);
}
}
SSLEngineResult result = sslEngine.wrap(src, outNetBuffer);
if (SessionLog.isDebugEnabled(session)) {
SessionLog.debug(session, Wrap res: + result);
}
if (result.getStatus() == SSLEngineResult.Status.OK) {
if (result.getHandshakeStatus() ==
SSLEngineResult.HandshakeStatus.NEED_TASK) {
doTasks();
}
} else {
throw new SSLException(SSLEngine error during encrypt:
+ result.getStatus() + src: + src
+ outNetBuffer: + outNetBuffer);
}
}
outNetBuffer.flip();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-637) SSLEngine output buffer seems to be too small
[
https://issues.apache.org/jira/browse/DIRMINA-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12649045#action_12649045
]
Emmanuel Lecharny commented on DIRMINA-637:
---
Acn you do a svn diff, and attach the result in this JIRA ? It will be easier
to inject in trunk.
Thanks !
SSLEngine output buffer seems to be too small
-
Key: DIRMINA-637
URL: https://issues.apache.org/jira/browse/DIRMINA-637
Project: MINA
Issue Type: Bug
Components: Filter
Affects Versions: 1.1.1, 1.1.7
Reporter: Dan Mihai Dumitriu
Assignee: Emmanuel Lecharny
Fix For: 1.1.8
the code below is in SSLHandler.java. it makes the assumption that the size
of the output will never be larger than 2x the size of the input. that
assumption appears to not hold up. It looks like this code has been fixed in
trunk, but not in 1.1.7. we only see an error for VERY specific content,
i.e. almost never.
public void encrypt(ByteBuffer src) throws SSLException {
if (!initialHandshakeComplete) {
throw new IllegalStateException();
}
// The data buffer is (must be) empty, we can reuse the entire
// buffer.
outNetBuffer.clear();
// Loop until there is no more data in src
while (src.hasRemaining()) {
if (src.remaining() ((outNetBuffer.capacity() - outNetBuffer
.position()) / 2)) {
// We have to expand outNetBuffer
// Note: there is no way to know the exact size required, but
enrypted data
// shouln't need to be larger than twice the source data size?
outNetBuffer = SSLByteBufferPool.expandBuffer(outNetBuffer,
src
.capacity() * 2);
if (SessionLog.isDebugEnabled(session)) {
SessionLog.debug(session, expanded outNetBuffer:
+ outNetBuffer);
}
}
SSLEngineResult result = sslEngine.wrap(src, outNetBuffer);
if (SessionLog.isDebugEnabled(session)) {
SessionLog.debug(session, Wrap res: + result);
}
if (result.getStatus() == SSLEngineResult.Status.OK) {
if (result.getHandshakeStatus() ==
SSLEngineResult.HandshakeStatus.NEED_TASK) {
doTasks();
}
} else {
throw new SSLException(SSLEngine error during encrypt:
+ result.getStatus() + src: + src
+ outNetBuffer: + outNetBuffer);
}
}
outNetBuffer.flip();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (FTPSERVER-220) does not processed correct user's empty password
[
https://issues.apache.org/jira/browse/FTPSERVER-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Gorobchuk reopened FTPSERVER-220:
--
the class org.apache.ftpserver.usermanager.impl.PropertiesUserManager
in the method authenticate(Authentication)
contains code for extracting declared user's password and condition for
checking this value.
code :
String storedPassword = userDataProp.getProperty(PREFIX + user
+ '.' + ATTR_PASSWORD);
if (storedPassword == null) {
// user does not exist
throw new AuthenticationFailedException(Authentication
failed);
}
this code produces AuthenticationFailedException in the case of declaring empty
user's password.
Imho, if aim of condition check of existing user (according to comment) more
correctly use following condition
if (!doesExist(user)) {
// user does not exist
throw new AuthenticationFailedException(Authentication
failed);
}
this case will check that user exists without links to password
Current implementation of PropertiesUserManager does not allow using user's
empty password for case of configured encrypted mode clear.
does not processed correct user's empty password
Key: FTPSERVER-220
URL: https://issues.apache.org/jira/browse/FTPSERVER-220
Project: FtpServer
Issue Type: Bug
Components: Server
Affects Versions: 1.0-M3
Reporter: Oleg Gorobchuk
Assignee: Niklas Gustavsson
Fix For: 1.0-M4
In the case if user has declared empty password server does not allow to
connect user.
Empty password does not processed for normal user and anonymous and for all
encrypted modes.
Sources of problem.
1. command PASS blocked using empty password since in this case request
contains NULL instead password value and command generates error 501
2. In the case of using properties way of user management
the class PropertiesUserManager, for case of configured empty password, makes
decision that user does not exist.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (FTPSERVER-220) does not processed correct user's empty password
[
https://issues.apache.org/jira/browse/FTPSERVER-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12649060#action_12649060
]
olegg edited comment on FTPSERVER-220 at 11/19/08 6:50 AM:
the class org.apache.ftpserver.usermanager.impl.PropertiesUserManager
in the method authenticate(Authentication)
contains code for extracting declared user's password and condition for
checking this value.
code :
String storedPassword = userDataProp.getProperty(PREFIX + user
+ '.' + ATTR_PASSWORD);
if (storedPassword == null) {
// user does not exist
throw new AuthenticationFailedException(Authentication
failed);
}
this code produces AuthenticationFailedException in the case of declaring empty
user's password.
Imho, if aim of condition check of existing user (according to comment) more
correctly use following condition
if (!doesExist(user)) {
// user does not exist
throw new AuthenticationFailedException(Authentication
failed);
}
this case will check that user exists without links to password
Current implementation of PropertiesUserManager does not allow using user's
empty password for case of configured encrypting mode clear.
was (Author: olegg):
the class org.apache.ftpserver.usermanager.impl.PropertiesUserManager
in the method authenticate(Authentication)
contains code for extracting declared user's password and condition for
checking this value.
code :
String storedPassword = userDataProp.getProperty(PREFIX + user
+ '.' + ATTR_PASSWORD);
if (storedPassword == null) {
// user does not exist
throw new AuthenticationFailedException(Authentication
failed);
}
this code produces AuthenticationFailedException in the case of declaring empty
user's password.
Imho, if aim of condition check of existing user (according to comment) more
correctly use following condition
if (!doesExist(user)) {
// user does not exist
throw new AuthenticationFailedException(Authentication
failed);
}
this case will check that user exists without links to password
Current implementation of PropertiesUserManager does not allow using user's
empty password for case of configured encrypted mode clear.
does not processed correct user's empty password
Key: FTPSERVER-220
URL: https://issues.apache.org/jira/browse/FTPSERVER-220
Project: FtpServer
Issue Type: Bug
Components: Server
Affects Versions: 1.0-M3
Reporter: Oleg Gorobchuk
Assignee: Niklas Gustavsson
Fix For: 1.0-M4
In the case if user has declared empty password server does not allow to
connect user.
Empty password does not processed for normal user and anonymous and for all
encrypted modes.
Sources of problem.
1. command PASS blocked using empty password since in this case request
contains NULL instead password value and command generates error 501
2. In the case of using properties way of user management
the class PropertiesUserManager, for case of configured empty password, makes
decision that user does not exist.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-220) does not processed correct user's empty password
[ https://issues.apache.org/jira/browse/FTPSERVER-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12649064#action_12649064 ] Niklas Gustavsson commented on FTPSERVER-220: - In org.apache.ftpserver.clienttests.LoginTest.testLoginWithEmptyCorrectPassword() we try to test for this, and in this case testuser3 has the following configuration of the password: ftpserver.user.testuser3.userpassword= It seems to work, what am I missing? does not processed correct user's empty password Key: FTPSERVER-220 URL: https://issues.apache.org/jira/browse/FTPSERVER-220 Project: FtpServer Issue Type: Bug Components: Server Affects Versions: 1.0-M3 Reporter: Oleg Gorobchuk Assignee: Niklas Gustavsson Fix For: 1.0-M4 In the case if user has declared empty password server does not allow to connect user. Empty password does not processed for normal user and anonymous and for all encrypted modes. Sources of problem. 1. command PASS blocked using empty password since in this case request contains NULL instead password value and command generates error 501 2. In the case of using properties way of user management the class PropertiesUserManager, for case of configured empty password, makes decision that user does not exist. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [PROPOSAL] Create a MINA subproject to implement a SSH server based on Mina
Great idea...great code! On Nov 19, 2008, at 4:27 AM, Guillaume Nodet wrote: I guess the next step is to start a formal vote about that, right ? As I've been the only committer on the project, I don't think a software grant would be needed for that. On Thu, Nov 13, 2008 at 3:07 PM, Guillaume Nodet [EMAIL PROTECTED] wrote: A few weeks ago, I've started a small project at googlecode to implement an SSH server in Java based on Mina. You'll find some background at http://gnodet.blogspot.com/ The project is still in its early stage and require a lot more work to be fully usable, but I've been doing some tests and the basic SSH protocol itself is implemented. The project is available at http://code.google.com/p/sshd/ My thinking is that it would be a good candidate to become a subproject of Mina (along with ftpserver and asyncweb), so i'm starting this discussion to gauge the interest of the MINA TLP to host such a subproject. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[Vote] Create a MINA subproject to implement a SSH server based on Mina
Hi guys, Guillaume Nodet has written a SSH server based on MINA, and as we discussed it last week, it would be interesting to have it as a subproject. It's time for a formal vote then : [] +1 Yes, accept the SSH server as a sub-project [] +/-0 I don't really care [] -1 Nope, it does not belong to MINA -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [Vote] Create a MINA subproject to implement a SSH server based on Mina
[X] +1 Yes, accept the SSH server as a sub-project On Wed, Nov 19, 2008 at 6:21 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Hi guys, Guillaume Nodet has written a SSH server based on MINA, and as we discussed it last week, it would be interesting to have it as a subproject. It's time for a formal vote then : [] +1 Yes, accept the SSH server as a sub-project [] +/-0 I don't really care [] -1 Nope, it does not belong to MINA -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [Vote] Create a MINA subproject to implement a SSH server based on Mina
On Thu, Nov 20, 2008 at 12:21 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: [X] +1 Yes, accept the SSH server as a sub-project /niklas
