Community
Participate
Working Groups
This is about the Web Connector. (PS: can you please create a web connector component on bugzilla?) I'm still trying to make the web connector work with a secured mantis installation. There is a bug on login page computation when using POST method. Also, after fixing this, I noticed that it returns a redirect URL which is not working (the URL is correct, but the GET implementation is not).
Created attachment 54519 [details] Patch
Created attachment 54520 [details] mylar/context/zip
Regarding the redirect problem, I'm not sure if this is the best approach (I'm not fluent on http internals). The server is returning a "login_cookie_test.php?return=my_view_page.php" as the redirect URL; I just discovered that appending a "/" in front of URI was sufficient to fix my case.
Created attachment 54530 [details] Updated patch Updated redirect codes handling according to Erkki's comments on bug#151602 comment#57. Also, I applied the code formatter.
Created attachment 54531 [details] mylar/context/zip
Is there a public issue tracker that can be used to test those changes? We need to keep WebRepositoryconnectorTest up to date with those changes...
(In reply to comment #6) > Is there a public issue tracker that can be used to test those changes? We need > to keep WebRepositoryconnectorTest up to date with those changes... > For manual tests I think you can use the Mantis demo site: http://www.futureware.biz/mantisdemo/my_view_page.php Now for automated tests... can't you make a bugzilla template and use it against Mylar own bugzilla test installations?
Eugene already has template tests, so if Willian asserts that this patch has been manually tested I can apply it. I would suggest writing a mock test for the patch even if it doesn't do any connection testing. Eugene, since this is your component now let me know when you want me to apply. I added a connector called "Web" (I realize that name is overly generic, but it will help prevent name bloat) and Eugene is the default asisgnee in light of his impending committer status.
What I can suggest is to create some user in that mantis repository and add a hack into WebRepositoryConnectorTest to login with this user. I think that it is a bad idea to use mock tests for concrete repository templates or http retrieval logic. Mocks should not simulate any infrastructure.
Should I apply this patch so that it makes it into this afternoon's RC1?
(In reply to comment #10) > Should I apply this patch so that it makes it into this afternoon's RC1? > Well, without this patch, the POST authentication and redirection handling is simply unusable... My only concern is about is about the quality of redirection implementation, but this can be discussed later.
(In reply to comment #8) > Eugene already has template tests, so if Willian asserts that this patch has > been manually tested I can apply it. I tested it against a private third party installation of Mantis. It didn't work :), so this patch is the result of my debug session. Unfortunately, the authentication support patch only cames out last week, there is a good chance to more bugs to appear after the release with other users trying to use in a variety of combinations... we'll have to live with it.
Mik, I won't be able to look at this before late tonight. So, it is probablt makes sense to apply this patch. Willian, in a mean time can you register a test account on mantis demo site and update WebRepositoryConnectorTest to use these credentials?
Patch applied.
(In reply to comment #13) > Willian, in a mean time can you register a test account on mantis demo site and > update WebRepositoryConnectorTest to use these credentials? Humm... I'll take a look...
(In reply to comment #13) > Willian, in a mean time can you register a test account on mantis demo site and update WebRepositoryConnectorTest to use these credentials? Sorry for the delay, 2 questions: 1 - For what I understood reading the WebRepositoryConnectorTest, it just iterates through the templates trying to connect, but the test is not prepared for authentication test (e.g. the hack to test otrs repository). Should I just introduce other "hack" to insert the mantis credentials? 2 - If (1) is right, then should we create a account on the existing mantis official installation (not sure if it is a good idea to play with a production environment) or create a account on the mantis demo installation and change the template to point there?
(In reply to comment #16) > 1 - For what I understood reading the WebRepositoryConnectorTest, it just > iterates through the templates trying to connect, but the test is not prepared > for authentication test (e.g. the hack to test otrs repository). Should I just > introduce other "hack" to insert the mantis credentials? I'd do that for now. Maybe later we can move to same mechanism Mylar is using for Bugzilla, Trac and JIRA. > 2 - If (1) is right, then should we create a account on the existing mantis > official installation (not sure if it is a good idea to play with a production > environment) or create a account on the mantis demo installation and change the > template to point there? I just want these templates to be using some projects related to Eclipse. That one seem good one. Another oprion could be SvnKit. We are only reading, so it should be ok, to use non-demo install.
I created the user mylar-test, pass mylar-test on mantis official installation, but there is something weird in that reverting this bug's patch, the tests are still working... Unfortunately I won't have time to investigate this in deep until the weekend, but I wonder if there is a bug on the tests. For this reason, I won't submit the test-patch yet.
This redirect implementation caused Bug #167282 . With that fixed, this works fine for me.
Downgrading severity. Rest of changes need to wait post-1.0.
Let me know if there's anything on this that should make it into 1.0.1, in which case we need to have it integrated sometime on Wednesday.
Weird... I commented out setFollowRedirect(false) and removed manual redirecting and all current tests are suddenly passing now. Mik, I wonder I should commit that and we should try dev build with this change.
Willian, Erkki, do we have anything left here? It seems like changes/patches in bug 167282 resolved these issues?
(In reply to comment #23) > Willian, Erkki, do we have anything left here? It seems like changes/patches in > bug 167282 resolved these issues? Yes, I think it's all working ok now.
Marking resolved.
