My team and I are currently exploring different methods of collecting email addresses from our website visitors.
We want to do something cooler than a contact forms, and we really like the way quicksprout.com handles this and would like to do the same.
Where would I start to implement collecting email addresses through a couple clicks of a mouse via connecting our visitors through google plus api from our homepage? Is this possible to implement through a regular http static html site?
NO A server is needed in order to collect email addresses. At least in order to add them to a database. This can not be done using just a static html site.
Now, since a server will be needed, you can just access the emails like link (This also avoids a hassle with Same Origin Policy)
For example: Let the user login via google oauth, save the user related email in your database. fine
(if the user has saved its login data in its browser or is already logged into its google account in the used browser, this would be a mouse click only solution.)
Related
I have created a URL for subscribing to calendar events, mainly in Outlook. Since it has private information, I want users to be able to authenticate when subscribing to this calendar URL using a username and password. I don't want users to add passwords in the URL in order to authenticate.
Is there a way to achieve this where potentially a dialog box appears in outlook where user can enter their security credentials or some other way to authenticate? I'm using node.js on server side.
Thanks in advance!
I don't believe there is a consistent way to do this:
The RFC5545 specification is meant to "provide the definition of a common format for openly exchanging calendaring and scheduling information across the Internet".
Ie the receiving application must be able to access the url. It may work for some if the application user is able to access the url at the time they are logged in, then fail at other times. This is what annoyed me intensely with a school application. One could login & download an ics file and import it BUT could not subscribe to it. So whenever there were updates at a minimum each term, one had to login and re download & import.
Option:
You could have people login and get their unique obfuscated url. This is how google calendar does it. It is a 'private' but public url - anyone who gets sent that url can subscribe to it. Since even if it weren't public, the person who logs in, could also download it and send the file around, there is only 'some' additional minimal risk.
At any stage if people are no longer authorised to access the URL, then for their url you issue a 410, or issue empty ics file, or one with dummy events .
Calendar subscription are just HTTP resources, so did you try to protect your resource with Basic Authentication, e.g. by using something like https://www.npmjs.com/package/basic-auth ?
I wish to add Social Login feature to a Shopify store that I am building. (I'm using the professional plan.)
I explored a few of the available social-login apps on the Shopify App Store. Upon studying closely as to how they actually work - I have come to the following understanding of the general scheme being followed by all of them.
The Shopify shop owner sets up a social app (e.g. Facebook app) with their store identity, but configures the Callback-URL/Redirect-URL to one supplied by the App author (i.e. pointing to their infrastructure).
Upon successful login by a shop customer on the social platform (via a link/button inserted on the shop login page), the request gets redirected to the App.
The App retrieves the user's email address from the their social profile (that they now have access to).
They then lookup their own database to see if this is an existing customer. If so they go directly to step 7 below.
If it's a new customer, they use Shopify API to create a new 'customer' on the target Shopify store. They set the customer up with a randomly generated password.
At the same time they also make an entry of this customer account (email + generated password) in their own database.
They then redirect the request back to the Shopify store's login page but this time with the customer's email address (retrieved from social platform) and their password (from the App's own database) included as part of the data that comes back to the users browser as part of loading the login page.
Then the App's javascript embedded on the shop login page uses the customer email address and password to programmatically submit the login form - thus establishing a valid customer session on the Shopify shop.
My questions are as follows:
Has someone else also looked closely in to this, and thus can validate if my above understanding is correct or not?
If it is correct - is this the only way to achieve social login on Shopify (without using Shopify Plus/Enterprise plan)?
I am trying to understand if this indeed is the only way, because I strongly feel that this method is not at all secure. And thus I'd rather not use this method; or if I just have to - then I'd rather write my own (private) app for this so that at least I am in control of the security of the app/database that holds sensitive users credentials.
Would appreciate any help/thoughts I can get with this, please.
If you are rolling your own you probably want to look at Multipass. It would be the thing to use if you can set up another web service that handles the trusted partner registration process.
Currently my service sends users an email with two links (action "A" and action "B"). Clicking on the link opens a new tab with action confirmation.
There was a desire to allow the user to select the action without opening a new tab, directly from the GMail.
To do this, I wanted to use the Email Markup, but it turned out that it only supports a single action. (I found it not in Email Markup docs, but on Stackoverflow, here)
As an alternative, I would like to use contextual gadgets, but the documentation says:
There are two development and deployment models:
Develop a Gmail contextual gadget for use within a single organization's Google Apps domains (an in-house application).
List the gadget for sale on the Google Apps Marketplace.
i.e. use gadgets for this purpose will not work.
Is there some other opportunity to allow users to select the action directly in the GMail?
I have written an agent which takes the username and authenticate user, if authentication is successful then it redirects to the actual URL of the database.
For taking name of the user, I am using #Formulas. Hence, I can use my method of authentication in any link or hotspot or button in Notes Client. But, I face problem to send this method through reminder email links.
When I create a URL through backend agent, this URL/hotspot should have my code with #formula. In simple words, I want to pass #Dblookup inside URL/hotspot through my email link. How to accomplish this task ?
Or is there any alternative to get user name if any person clicks a link in his email ?
Only Notes client has to be used.
Edit#1: Adding scenario for better explanation:
Our users are not happy to re-authenticate themselves for web applications. So, we have been trying something like if they want to open a webdoclink, which they got through their email in notes client, so they shouldn't be asked to authenticate again (since they have already logged into notes client).
We could achieve this for static application links, where application name is not changed. Now, the challenge we are facing is how to do it for reminder emails, which have links to particular web document (links here are not static. They are differed by unique document ids).
For this to work, we need shortname of person who clicked that link from his email.
You probably need to be sending an Action hotspot instead of a URL hotspot; but it is very difficult to guess without seeing what your code is really doing. Also, I believe that creating an Action hotspot probably will require copying it from a previously saved rich text field, perhaps in a profile document and appending it to the rich text body field of the message you are sending. (That's a technique I've used in the past to create action hotspots, anyhow. I'm not sure if there are better alternatives.)
And since this is for Notes client recipients, the other technique that I would probably explore is the use of a store-form-in-document message instead of an ordinary email message. That way you just need to have a button containing the #DbLookup on the form that you send in the message.
I agree with leyer. The ACL (Access Control List) is the main tool to use to decide functionality. For instance a user can have access to the db. Then you can define who can create databases, create emails. It is best to use the ACL so you can also use Roles and other tools. Basic LotusScript can access the ACL on open events or do a test in buttons.
Regarding the scenario you are describing, if the issue is that users have to re-authenticate for every web application on the server, you would be better of implementing SSO/Session based authentication on the server then coding this workaround. With Session based authentication, users only have to authenticate once.
From the admin help:
Session-based name-and-password authentication sends the client's name and unencrypted password, and is sent with each request to the server. Session-based authentication differs in that the user's name and password information is sent over the network only the first time the user logs in to a server, not each time a request is posted. After login, the user's name and logon information is stored in a cookie in the user's browswer, and the browser sends the cookie to the server with each request. Before honoring a request, the server verifies the information in the cookie and uses the cookie contents to identify the logged-in user. The session is only valid within the browser in which the login was performed. If the user shuts down the browser in which the session login took place, the user's session will be ended and the cookie will be destroyed.
Using session-based name-and-password authentication provides greater control over user interaction than basic name-and-password authentication. For example, you can customize the form in which users enter their name and password information. It also allows users to log out of the session without closing the browser.
If you are using windows based servers, you could even implement SPNEGO, automatically signing the users in using der Windows account, therefore eliminating login prompts completely.
With Domino 9, you also have the option of using Security Assertion Markup Language (SAML) to configure federated-identity authentication.
In your case, I would start with Session-based name-and-password authentication to solve the multiple-login issue.
I'm working on a GMail gagdget and am trying to access the current users ComanyName / Apps-Account-DomainName / ID. It has to be some ID thats unique for all users belonging to the same Google Apps Domain, for I like to display different content to different users beeing in the same Domain / Company.
Do you know if and how this is possible?
As far as I understand it, GMail sidebar gadgets are not able to access any of the current users data. They are just displayed within gmail, but don't interagate with it.
Unless you use OAuth to authenticate the user.
This for example shows how to get the users contacts:
http://gadget-doc-examples.googlecode.com/svn/trunk/opensocial-gadgets/oauth-contacts.xml
Observing the code you will see, that it uses a feed to access this data:
http://www.google.com/m8/feeds/contacts/default/base?alt=json
So maybe my question is: "Which feed do I have to access to get the Google Apps domain of the user?" Otherwise: Is it possible at all?
This piece of code solved my problem:
var domain = gadgets.util.getUrlParameters()['parent'].match(/.+\/a\/(.+)\/html/)[1];
Got the answer over here:
http://www.google.com/support/forum/p/apps-apis/thread?tid=3d0d1c7033431d79&hl=en