[ARQ-1321] Support for HTTPS in URLs injected with @ArquillianResource

[samaxes]

This change is

[aslakknutsen]

If you haven't noticed, we're having a little naming/sementics discussion on twitter around this:

https://twitter.com/aslakknutsen/status/308875252237213696

:)

[samaxes]

protocol and port elements were added to the @Secured annotation.
I would love to hear your comments on this feature.

[gastaldi]

For consistency, I think @secure may be more appropriate (without the 'd'). Thoughts ?

[bartoszmajsak]

But you don't secure it here, you expect to have secured one injected.

[samaxes]

@bartoszmajsak you may close this PR, it's super outdated and this has already been implemented here: https://github.com/arquillian/arquillian-showcase/tree/master/extensions/arquillian-smart-url.
However, this should probably be available in the core instead of the showcase project.

[bartoszmajsak]

I was just wondering what is the status of this, as it looks like a pretty valid functionality. I will look into the extension then. Thanks for your contribution

[samaxes]

@aslakknutsen Have you had the time to check this PR?

[lordofthejars]

@bartoszmajsak what we can do with this? We integrate smart-url in core?

[bartoszmajsak]

@lordofthejars should we?

[lordofthejars]

@bartoszmajsak in my opinion I would merge this PR and avoid more complicated things.

[bartoszmajsak]

I wouldn't merge right away. I would compare with the extension from the showcase first. + take into consideration the discussion on twitter mentioned above.

[arjantijms]

@aslakknutsen Have you already had the time to check this PR?

[arjantijms]

@aslakknutsen @bartoszmajsak @lordofthejars @starksm64 this issue is the one that was recently discussed during a call about the TCK moving to Arquillian.

Having the HTTPS URL is required by various tests. I understand there's a ton of difficulty around this and it's not trivial to review, but has there been any progress here in those 8 years?

[bartoszmajsak]

@aslakknutsen @bartoszmajsak @lordofthejars @starksm64 this issue is the one that was recently discussed during a call about the TCK moving to Arquillian.

Having the HTTPS URL is required by various tests. I understand there's a ton of difficulty around this and it's not trivial to review, but has there been any progress here in those 8 years?

Not that I'm aware of. @aslakknutsen can you chime in?

[aslakknutsen]

I won't comment on @secure vs @secured and the likes, nor have I been much involved in the project the last 5 ish years, how ever...

On top of my head I could see the current impl as provided here as a possible fallback/backwards compatible version, the reason being that the Injection of URLs are intended to come from the Container to avoid hard coding them in the test case. The way this is implemented now would force the Test case to only run on Containers that e.g. use 8443 as a port.

Following the ProtocolMetadata SPI that is returned by the DeployableContainer on deploy, I would have rather added either a HTTPSContext or added a secure field to the HTTPContext (and thereby adding two HTTPContexts to the ProtocolMetadata). The @secured simply switch between the two contexts, but port numbers etc are still provided by the DeployableContainer.

[starksm64]

@arjantijms Is there a requirement in terms of what the unit test class is doing? I looked at some threads the TCK list but did not see this issue mentioned.

[arjantijms]

@starksm64 for the Client-Cert test in Servlet, a request to the HTTPS URL is needed. The test for the WebUserDataPermission in authorization and the mirroring transportType in Servlet need it too.

[starksm64]

Replaced with #474 since this PR could not be updated via the github interface