[jira] [Commented] (SSHD-107) Extend SshFile etc views to scp command
[ https://issues.apache.org/jira/browse/SSHD-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015874#comment-13015874 ] Richard Evans commented on SSHD-107: Yes, I've verified the functionality in HEAD. It's fine. Richard > Extend SshFile etc views to scp command > --- > > Key: SSHD-107 > URL: https://issues.apache.org/jira/browse/SSHD-107 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 0.5.0 >Reporter: Richard Evans >Priority: Minor > Fix For: 0.6.0 > > > Following the changes for SSHD-82, we have successfully integrated sshd into > our server application and sftp works well. It would be nice to allow the > use of scp also since that is sometimes simpler from the client side. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SSHD-109) Pass server session to FileSystemFactory.createFileSystemView
[ https://issues.apache.org/jira/browse/SSHD-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015873#comment-13015873 ] Richard Evans commented on SSHD-109: Yes, I've verified the functionality in HEAD. It's fine. Richard > Pass server session to FileSystemFactory.createFileSystemView > - > > Key: SSHD-109 > URL: https://issues.apache.org/jira/browse/SSHD-109 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 0.5.0 >Reporter: Richard Evans >Priority: Minor > > In the integration of sshd with our application we have a > PasswordAuthenticator implementation which authenticates against our internal > user database. From this we derive an internal user object which is needed > for further permissions checking, etc in the file system view. However the > createFileSystemView call takes a user name only. If the ServerSession was > passed to createFileSystemView also, the user object could be stored in the > session and retrieved when the file system view is created. In the current > system I have to store the user object in a ThreadLocal and get it from there > in createFileSystemView. > This would require a custom session factory and session object - if the > session had some internal storage for private attributes, etc (rather like an > HttpSession) this would not be necessary. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SSHD-111) Support gssapi-with-mic authentication to use kerberos credentials
[ https://issues.apache.org/jira/browse/SSHD-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012888#comment-13012888 ] Richard Evans commented on SSHD-111: We'd like to use this feature in our embedding of sshd - we already support kerberos/gssapi authentication for the app itself. Any chance of this patch getting added to the code? Thanks Richard > Support gssapi-with-mic authentication to use kerberos credentials > -- > > Key: SSHD-111 > URL: https://issues.apache.org/jira/browse/SSHD-111 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 0.5.0 >Reporter: Richard Evans >Priority: Minor > Attachments: gss.patch > > > I recently raised a couple of improvements which duplicated existing issues > and which were fixed in HEAD. Hope this one is not. > I've made some changes to support gssapi-with-mic authentication allowing > access to the server without entering a password if in a Kerberos > environment. This is beneficial for us because we embed sshd in an > application which already provides single sign on using GSSAPI in Unix and > Windows. > A patch is attached. The core of the code is in UserAuthGSS; the > GSSAuthenticator class is provided to allow parts of the process to be > overridden for different environments - for example using a native > implemention of GSSManager on Windows to provide easy integration with AD. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SSHD-111) Support gssapi-with-mic authentication to use kerberos credentials
Support gssapi-with-mic authentication to use kerberos credentials -- Key: SSHD-111 URL: https://issues.apache.org/jira/browse/SSHD-111 Project: MINA SSHD Issue Type: Improvement Affects Versions: 0.5.0 Reporter: Richard Evans Priority: Minor Attachments: gss.patch I recently raised a couple of improvements which duplicated existing issues and which were fixed in HEAD. Hope this one is not. I've made some changes to support gssapi-with-mic authentication allowing access to the server without entering a password if in a Kerberos environment. This is beneficial for us because we embed sshd in an application which already provides single sign on using GSSAPI in Unix and Windows. A patch is attached. The core of the code is in UserAuthGSS; the GSSAuthenticator class is provided to allow parts of the process to be overridden for different environments - for example using a native implemention of GSSManager on Windows to provide easy integration with AD. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SSHD-111) Support gssapi-with-mic authentication to use kerberos credentials
[ https://issues.apache.org/jira/browse/SSHD-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Evans updated SSHD-111: --- Attachment: gss.patch Patch for gssapi-with-mic authentication, against HEAD. > Support gssapi-with-mic authentication to use kerberos credentials > -- > > Key: SSHD-111 > URL: https://issues.apache.org/jira/browse/SSHD-111 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 0.5.0 >Reporter: Richard Evans >Priority: Minor > Attachments: gss.patch > > > I recently raised a couple of improvements which duplicated existing issues > and which were fixed in HEAD. Hope this one is not. > I've made some changes to support gssapi-with-mic authentication allowing > access to the server without entering a password if in a Kerberos > environment. This is beneficial for us because we embed sshd in an > application which already provides single sign on using GSSAPI in Unix and > Windows. > A patch is attached. The core of the code is in UserAuthGSS; the > GSSAuthenticator class is provided to allow parts of the process to be > overridden for different environments - for example using a native > implemention of GSSManager on Windows to provide easy integration with AD. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SSHD-109) Pass server session to FileSystemFactory.createFileSystemView
Pass server session to FileSystemFactory.createFileSystemView - Key: SSHD-109 URL: https://issues.apache.org/jira/browse/SSHD-109 Project: MINA SSHD Issue Type: Improvement Affects Versions: 0.5.0 Reporter: Richard Evans Priority: Minor In the integration of sshd with our application we have a PasswordAuthenticator implementation which authenticates against our internal user database. From this we derive an internal user object which is needed for further permissions checking, etc in the file system view. However the createFileSystemView call takes a user name only. If the ServerSession was passed to createFileSystemView also, the user object could be stored in the session and retrieved when the file system view is created. In the current system I have to store the user object in a ThreadLocal and get it from there in createFileSystemView. This would require a custom session factory and session object - if the session had some internal storage for private attributes, etc (rather like an HttpSession) this would not be necessary. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SSHD-108) Add upload monitoring to sftp and scp
Add upload monitoring to sftp and scp - Key: SSHD-108 URL: https://issues.apache.org/jira/browse/SSHD-108 Project: MINA SSHD Issue Type: Improvement Affects Versions: 0.5.0 Reporter: Richard Evans Priority: Minor We have sshd integrated into our application and sftp is working fine. One of the requirements is to initiate some action when a file upload it complete. I have made this work by implementing handleClose in my SshFile implementation and performing the action if createOutputStream had been called previously. This seems a bit ugly though; it might be nicer if there was some plug in mechanism to monitor file transfers. Ideally the monitor would be able to distinguish between a successful upload and a cancelled one (via ctrl-c at the client), but a quick perusal of the sftp stuff seems to inidicate that this is not possible. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SSHD-107) Extend SshFile etc views to scp command
Extend SshFile etc views to scp command --- Key: SSHD-107 URL: https://issues.apache.org/jira/browse/SSHD-107 Project: MINA SSHD Issue Type: Improvement Affects Versions: 0.5.0 Reporter: Richard Evans Priority: Minor Following the changes for SSHD-82, we have successfully integrated sshd into our server application and sftp works well. It would be nice to allow the use of scp also since that is sometimes simpler from the client side. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FTPSERVER-361) Provide more information on command execution to Ftplets - especially file created in STOU
[ https://issues.apache.org/jira/browse/FTPSERVER-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850872#action_12850872 ] Richard Evans commented on FTPSERVER-361: - I see - the reply would indicate the file that was stored, etc. Can I suggest a new methods on DefaultFtpLet which are called with the reply object cast to the correct class for the command? eg. public FtpletResult onUploadEnd(FtpSession session, FtpRequest request, DataTransferFtpReply reply) put I guess this would fail if the reply indicated some failure? > Provide more information on command execution to Ftplets - especially file > created in STOU > -- > > Key: FTPSERVER-361 > URL: https://issues.apache.org/jira/browse/FTPSERVER-361 > Project: FtpServer > Issue Type: Improvement > Components: Ftplets >Affects Versions: 1.0.4 >Reporter: Richard Evans > > To monitor file uploads, I can configure an Ftplet and override onUploadEnd > and onUploadUniqueEnd in DefaultFtplet. However I cannot find a way to > determine the real file that was written in the upload. > For a non-unique upload I can get the argument and resolve it against the > working directory in the file system view; but this seems unnecessarily > complex and does not for for unique uploads (STOU) because the random file > name is not available. > Browsing the code I can see the file observer stuff, but these are non-public > APIs and there can be only one observer at a time whilst I can have many > independent Ftplets implementing the onUpload APIs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-361) Provide more information on command execution to Ftplets - especially file created in STOU
Provide more information on command execution to Ftplets - especially file created in STOU -- Key: FTPSERVER-361 URL: https://issues.apache.org/jira/browse/FTPSERVER-361 Project: FtpServer Issue Type: Improvement Components: Ftplets Affects Versions: 1.0.4 Reporter: Richard Evans To monitor file uploads, I can configure an Ftplet and override onUploadEnd and onUploadUniqueEnd in DefaultFtplet. However I cannot find a way to determine the real file that was written in the upload. For a non-unique upload I can get the argument and resolve it against the working directory in the file system view; but this seems unnecessarily complex and does not for for unique uploads (STOU) because the random file name is not available. Browsing the code I can see the file observer stuff, but these are non-public APIs and there can be only one observer at a time whilst I can have many independent Ftplets implementing the onUpload APIs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
