Skip to content
This repository has been archived by the owner on Apr 25, 2023. It is now read-only.

Fix disappearing newsletter subscription form under https #117

Closed
2 of 8 tasks
cbeams opened this issue Nov 8, 2013 · 8 comments
Closed
2 of 8 tasks

Fix disappearing newsletter subscription form under https #117

cbeams opened this issue Nov 8, 2013 · 8 comments
Assignees

Comments

@cbeams
Copy link
Contributor

cbeams commented Nov 8, 2013

  • see if we should use spring-ws or marketo's jar API
  • get credentials (username, secret key, SOAP endpoint)
  • get specific SOAP args for spring.io when creating a lead (lead source, munchkin ids...)
  • integrate HTML+CSS for newsletter form and remove iframe code
  • create a SOAP client
  • create a REST endpoint

Our current HSTS configuration forces https everywhere on the site, resulting in internal users copying and pasting https urls instead of http. This is problematic because there are https-related bugs in a couple areas on the site, and external users shouldn't be exposed to these.

@cbeams
Copy link
Contributor Author

cbeams commented Dec 20, 2013

On Dec 17, 2013, at 11:50 PM, @phumphrey wrote:

ping on this. Where is this fitting in current priority stack?

It remains in the backlog without any particular priority. Is this continuing to come up as a problem for you as described above? Perhaps @rwinch would be interested in putting together a pull request. Rob?

@cbeams
Copy link
Contributor Author

cbeams commented Dec 22, 2013

On Dec 20, 2013, at 8:26 PM, @phumphrey wrote:

I ask because I know that I have been copy and pasting https:// URls everywhere in my promo materials, considering sending a mail to dev list, devrel, everyone to ask that they make sure to use http:// form of the URL when linking to things -- that wasy the subscribe button isn't broken.

@cbeams
Copy link
Contributor Author

cbeams commented Dec 22, 2013

Roger that, @phumphrey. Hopefully @rwinch can weigh in here, though it might understandably be post-holidays.

@rwinch
Copy link
Contributor

rwinch commented Jan 2, 2014

HSTS specification does not allow you to configure based upon the URL only by domain. So we would need to create a unique domain for the admin users to be using and ensure we are using that domain anytime users were administering the application. For example, we might create a URL like secure.spring.io that we could then force users to HTTPS.

@gregturn
Copy link
Contributor

gregturn commented Jan 2, 2014

Sounds a bit complex to manage two domains. Imagine possible places where we have relative links going between admin and non admin. Is this what we really want?

Also smells like an update to spring security docs is in order to raise awareness of this in case devs are trying to do similar things on their own site.

Sent from my iPhone

On Jan 2, 2014, at 8:32 AM, Rob Winch notifications@github.com wrote:

HSTS specification does not allow you to configure based upon the URL only by domain. So we would need to create a unique domain for the admin users to be using and ensure we are using that domain anytime users were administering the application. For example, we might create a URL like secure.spring.io that we could then force users to HTTPS.


Reply to this email directly or view it on GitHub.

@cbeams
Copy link
Contributor Author

cbeams commented Jan 2, 2014

Thanks @gregturn, agreed re: complexity, etc. @rwinch and I just chatted via voice and landed on this as a plan:

  • leave the current HSTS settings in place—which actually do not send the Strict-Transport-Security: header unless and until the user requests something under /admin. This means that if a user clicks a link like https://spring.io/blog/xyz, they are not locked into HSTS. i.e. they can strip the https: back to http: and still view the content that way.
  • Fix the real underlying problem, which is that the newsletter subscription form is being brought in via an iframe that disappears under https (for as yet not fully understood reasons). What we ideally want to do sign folks up for the newsletter from our own domain, and ditch the iframe approach altogether. @jacksoncvm looked into this previously, and it looked like we were pretty stuck with slurping in this content from the gopivotal site, I believe due to Marketo-related restrictions. Chloe, we had this conversation under an email thread with the subject line "Marketo URL for posting email subscriptions?". Could you look back into this issue, talk with Christina D. again, perhaps, and see what we can do? It would think must be possible—some way—to manage Marketo newsletter subscriptions from multiple domains...? It seems we really need to dig into this and actually solve it.

@ghost ghost assigned jacksoncvm Jan 2, 2014
@jacksoncvm
Copy link
Contributor

For now, we could put the 'Subscribe to our Newsletter' text inside the iframe so at least it doesn't look broken.

The Pivotal Network team has started using the Marketo API. I'm assuming we could do the same. I'll ask them if they have any tips.

@jacksoncvm
Copy link
Contributor

Just heard back. They said they'd send their code over later this week. Meanwhile, I can work on the iframe change (to include the 'subscribe' text in the frame).

cbeams pushed a commit that referenced this issue Jan 7, 2014
This adds the 'subscribe to our newsletter' text to the
newsletter subscription iframe so that when the iframe disappears
in https, the section won't look like it's broken (as discussed
in #117)
@bclozel bclozel assigned bclozel and unassigned jacksoncvm May 1, 2014
@bclozel bclozel closed this as completed Dec 15, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

No branches or pull requests

5 participants