I've got a flex app that is basically completed it uses Zend AMF to connect/supply data.
My app does have a login screen which seems to work fine. Now I'd like to add another login form on my site that would allows users to enter in username/password. When submitted form should pass the data to the flex app and bypass the application's login.
The only way I know how to do this is by passing the users input in the url which is obviously not ideal.
How can I post the form data to use as variables in flex?
There are two more methods I use.
1) Pass parameters to your swf via html embed and read it in swf on load (using FlashVars):
http://kb2.adobe.com/cps/164/tn_16417.html
2) Write login data to browser cookies and read it in swf (using calls to JavaScript in your page via ExternalInterface):
Accessing browser cookies from Flex
I used library from checked answer to the question above, it's working.
Send your user's input to the server trough your form, if the login is successful, open your flex app.
Since it will be on the same session, your flex app will be able to get user’s information from the server and if it's there, bypass the flex app login.
Related
I want user will not redirect to login page on closing website or browser once user is loggedIn.for this i use localStorage. it is working successfully but, it works after page rendering in nextjs. so, it give me error for 5 seconds. i want to access localStorage before page rendering in nextjs.[![First image shown when website is launch
Local Storage is only available in the browser. It will not be available on the server (or while the page is doing any kind of server-side operation).
https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage
You should use a cookie to store this information if it needs to be accessible by both the server AND client.
I want to show my site inside the Salesforce iFrame, and when someone does any activity on my site inside the iFrame i want to update the Salesforce page as well?
Can i do this, please suggest?
A more recent approach, now GA, is Force.com Canvas - this is iframe-based with additional security and features, including passing context such as Salesforce fields into the iframe. It also enables the iframed web app to call Salesforce APIs based on that authentication, either via JavaScript or by your backend web app (Python, Java, etc) using the credentials from the Canvas framework.
You can also use the new Events feature within Canvas to send messages to the framing Salesforce page.
On authentication options: the Canvas Signed Request authentication is recommended and easy, but note that it doesn't give you a refresh token for OAuth2 - so if you need to do continuing background processing based on the user's authentication, you should use the Canvas OAuth2 authentication instead, which does give you a refresh token.
Overall, Canvas is cleaner than using a raw iframe and should simplify development. It does require some changes to authentication in the iframed web app but they are relatively simple (10 lines or so of Python).
You can use Javascript and page refreshing to send information to the parent window, but this isn't in my recommended books. iFrames are not meant to communicate with it's parent site for security reasons.
You might want to look into using an API to communicate between the two sites.
Scenario:
We provide a hosted site that clients pay to use internally (a tool to support their business workflow). We have a requirement to provide a form that the clients can 'embed' in their outward facing site. This form will permit a member of the public to enter some details to register an interest - this data will be pushed to our remote system.
Question:
I'm currently planning on creating a simple HTML page that the client's web guys can include in on their site with a minimum of technical knowledge required (either using an iframe or an object tag). If I do this, am I going to run into difficulties when the user tries to submit the embedded form (as it will be going to different domain to the one they are currently browsing)?
I had a look at google adsense and I see that they just provide a link to a JS file that renders their ads - I'm not sure I see the advantage in this, but if anybody has any bright ideas...
Whatever technique that gets used, I'll have to authenticate the request as coming from my client's site(s).
If I do this, am I going to run into difficulties when the user tries to submit the embedded form (as it will be going to different domain to the one they are currently browsing)?
No issues, you'll need to hardcode a post url into your form.
Whatever technique that gets used, I'll have to authenticate the request as coming from my client's site(s).
That may be difficult. The request will be coming from the user's browser.
You could make it a requirement for a client to define some JavaScript variable in the containing page, like:
var client_id = '2315213452';
and attach a script to pick up this value and submit to your server along with the form.
The trouble is, any hacker could see this value in plain text and take it thus compromising your security.
I created an application as part of an ASP.NET site. I would like to receive error notifications in my inbox whenever something goes wrong with that flash application.
As I do not have control over our mail server (which has a different domain name), I cannot establish a cross domain policy allowing me to send error emails to my inbox.
Instead, thought I'd send a request to an ASP.NET handler that sends an email on behalf of the flash app.
Now the problem: the error report should include a screenshot of the flash application at the time the error occurred. The FileReference class however only allows file uploads with user interaction (browse dialog) and cannot be used programmatically to send the screenshot to my ASP.NET handler. The plain old POST back only allows files up to ~200K.
Am I missing something or is there no alternative to :
using POST w/ a compressed or resized screenshot
or forcing the user to first save a screenshot and then select it for upload?
Thanks a bunch!
The problem lay in the receiving web service, not in Flex.
I have a Drupal site with user logins. Embedded within this site is a Flash application that shows some data to everybody but allows extra functionality if the user is logged on. From within Flash, I'm using XMLRPC to access the system.check method (to determine whether the user is logged in) and the user.login method (to log in a user from within Flash).
Within Flash, everything works fine. However the Flash login state does not seem to correspond to the rest of the site. For example, if I invoke user.login via XMLRPC, subsequent calls to system.check show that I am logged in, but the Drupal user page still says I'm logged out. Or if I am logged in both places and then I log out via the Drupal user page, the next call to system.check still indicates that I am logged in.
How can I make the login state consistent between the Drupal GUI and my embedded Flash app?
(Note: I am not using any XMLRPC library, I am just constructing the requisite XML manually and sending POST methods using a URLRequest object.)
EDIT: I have confirmed via this question and also via testing with a Web Proxy that the SESS cookie returned by the user login page is being picked up and sent back by the flash application.
EDIT: And now I have shown experimentally that even though Flash (via Safari) is sending the same cookie, it gets back a DIFFERENT cookie when it connects to the XMLRPC service than when it requests and HTML page. In other words, Drupal just doesn't support this kind of synchronization and I'm stuck. I'm accepting the answer below that put me on the right track.
EDIT: AMHPHP is not fully released for Drupal6 as of this writing, but it turned out to be installed on the site anyway. Using the DrupalSite library, I was very easily able to log into and out of the site from flash, and the login remained consistent between flash and HTML.
I'm not terribly familar with Flash, but do the URLRequest objects "inherit" state from the browser session, including the user login cookies? If not, you'll need to explicitly send the login cookie with your hand-built request or Drupal will think that it's just coming from another web browser at the same IP address.
If you're not quite sure, using the Firebug plugin might be useful. It lets you inspect any requests that are being piped through the browser, examine their headers, and look at the raw HTTP response object that comes back.
Update: Even more important than the flash widget getting a session cookie is the flash widget getting the SAME session cookie as the web browser itself. Drupal allows users to log in from multiple machines simultaneously, so if the browser is creating one session and the flash widget is creating another, you'd see the behavior you're describing...
It can't be done.
(For details, please see my final edit to the original question and the equivalent information in my comment to #Eaton.)