I'm new to the Webex API and am trying to run my first few calls. Starting with a login call, it looks to me like our REST url for that should be https://[ourSite].webex.com/[ourSite]/p.php?AT=LI
What I’m unclear about is how to authenticate. The documentation (page 2-22) doesn’t list username or password as fields that can be sent. The only field it lists as required is WID (Webex ID), which I assume is to be the authentication string? If so, how does one find this value? I do not see it in the user edit screen in site administration, which seems like the logical place for it to me. Is there some special screen I need to access for API information like this?
It would be https://sitename.webex.com/sitename/p.php?AT=LI&WID=[WebExID]
It used to allow passing account password, meeting passwords and partner IDs in the URL itself, but a security update removed that functionality, so they must be passed in an HTTP POST form. Example:
<form action="https://sitename.webex.com/sitename/p.php?AT=LI&WID=username" method="POST">
<input type="text" name="PW" value="">
<input type="submit">
</form>
Check out the blog post below for more details:
https://communities.cisco.com/community/developer/webex/blog/2016/02/11/recent-url-api-changes--get2post
Related
I submit the form to admin-post.php:
<form action="<?php echo admin_url('admin-post.php') ?>" method="post">
<input type="hidden" name="action" value="some-action">
<input type="text" name="somename">
</form>
And handle it in the backend:
add_action( 'admin_post_some-action', function () {
$isValid = // SOME VALIDATION HERE
if($isValid){
wp_redirect('next-step'); //redirect to the next form
return;
}
wp_redirect('current-step'); //redirect back
});
If the form is not valid, I want to redirect back to the form with filled data and highlighted invalid inputs. The problem is that wp_redirect does not return any data at all. So user will need to fill all the data mannually again without even understanding wjat was wrong. I found 2 solutions:
Use get param in the wp_redirect - it may be good for just one input, but it will be awful, especially for the file and passwords inputs.
Use $_SESSION - it's a bit better, but still rough way to implement this.
Use curl - it's very dirty solution for the WP
I guess there should be some simple default way to handle this, as it's quite major thing. Any ideas?
Use transients if the user is logged in and set them to expire about 60 seconds, setting the data in your admin_post action then retrieving them in your form page. I'm still looking for a nice solution that doesn't involve posting the form back to itself by setting action="" in the form and not using the admin_post action.
Whether 'simple' or 'hard' programming, instructions need to be given to the machine. Think about how would you accomplish it with just plain PHP. You are basically being redirected to another page after unsuccessful login. Since HTTP is stateless, you can store the data either on the server side (in database, session, files..) or you pass the information in the URL. WordPress wouldn't just automatically start a session for you to store last form submission.
I have setup a login page login.jsp. Whenever I go to login.jsp and specify additional query strings such as
login.jsp?hello
and click login, I get redirected to index.jsp and the ?hello query string is stripped off.
Is there a way to keep the query string?
If you're using container managed authentication, then this is not possible. It will only be automatically handled whenever the query string is actually in that restricted URL for which the enduser is been presented the login page first. The container would after a successful login automatically redirect back to the restricted URL, complete with the original query string.
If you're using homegrown authentication, then you just need to copy the current query string in the login URL. E.g.
<form action="login?${pageContext.request.queryString}" method="post">
<input type="text" name="username" />
<input type="password" name="password" />
<input type="submit" value="login" />
</form>
Then, in the servlet's doPost(), or wherever you're handling the login, then just grab the query string by HttpServletRequest.getQueryString() and pass it through on redirect. E.g.
User user = userService.find(username, password);
if (user != null) {
request.getSession().setAttribute("user", user); // Do whatever you need to represent a logged-in user.
response.sendRedirect(request.getContextPath() + "/index.jsp?" + request.getQueryString());
}
else {
// Show "unknown login" error?
}
All with all, I'm not sure how this functional requirement of having the query string in the login URL makes sense in real world. It would make more sense if that query string was part of the original restricted URL for which you'd need to login first, exactly as the standard container managed authentication mechanism supports. So perhaps you need to rethink the one and other again.
What is proper way to process forms in http?
on /somepage:
<form method="POST" action="/someaction.html">
<input type="text" name="name">
<input type="submit">
</form>
Let's assume, that user didn't filled in "name". So I should produce some error. How should I do it:
First method
POST /someaction and 302 Redirect to /posterror?error=1
GET /posterror?error=1 and 200 Ok with content about errors and form
Second
POST /someaction and 200 Ok with content about errors and form
Third
POST /someaction, remember in session form errors and 302 Redirect to /posterror
GET /posterror and 200 Ok with content about errors and form
Which one is proper way? Maybe some fourth one?
The correct approach is called post/redirect/get and is described by wikipedia as:
Post/Redirect/Get (PRG) is a common design pattern for web developers
to help avoid certain duplicate form submissions and allow user agents
to behave more intuitively with bookmarks and the refresh button.
The third one. It allows the user to safely hit refresh or bookmark the page. The first one, although similar, would require you to pass the content of form back and forth over the wire, which is inefficient. As slight refinements, you might consider:
Redirect back to the form, not to a separate error page, to give the user a chance to correct their error
Rather than just storing the error data in the session, store it with some unique id, and then include that in the redirect url. That way the user can can have the page open in two browser windows and they won't tread one each other's toes.
Expire the stored error after a set length of time, or when the form is finally correctly submitted.
I would suggest having some sort of validation before the for is sent using javascript.
Then of course you should validate the form input on the server side as well. As for whether to use redirects, I don't know of any de facto standard there.
If you want to follow use the HTTP protocol as it was meant you should probably send a 4xx status code back (e.g. 400 bad request) with an informative message saying what was wrong in the input.
Is utilizing client-side validation out of the equation? Using javascript you can avoid posting the form (and reduce server-side processing) and let the client (user's end: browser) perform the validation. What other validations do you have in mind?
Here's a link to basic validation that you can apply using javascript:
http://www.w3schools.com/js/js_form_validation.asp
I am using a wp blog and I want leads to come in to go to be via email and then get refered to another website with the values already filled in?
I want to use php, but i will use anything that works.
does anyone know how to do this?
In HTML, when marking-up a form, you can specify default values. So for example:
<form>
<input name="firstName" value="John">
<input name="lastName" value="Doe">
<button type="submit">
</form>
So, once the user submits data from the first form, you can write the HTML in the second page with the user's information placed into the form already. By default it will be there, but it could be edited again if he/she chooses.
I don't use WP, but I'm sure you can grab the data coming from the first form, then emit the same when generating the next page.
Scenario:
The task I have at hand is to enable a single-signon solution between different organizations/websites. I start as an authenticated user on one organization's website, convert specific information into an Xml document, encrypt the document with triple des, and send that over as a post variable to the second organizations login page.
Question:
Once I have my xml data packaged, how do I programmatically perform a post to the second website and have the user's browser redirected to the second website as well.
This should behave just like having a form like:
action="http://www.www.com/posthere" method="post"
... and having a hidden text field like:
input type="hidden" value="my encrypted xml"
This is being written in asp.net 2.0 webforms.
--
Edit: Nic asks why the html form I describe above will not work. Answer: I have no control over either site; I am building the "middle man" that makes all of this happen. Site 1 is forwarding a user to the page that I am making, I have to build the XML, and then forward it to site 2. Site 1 does not want the user to know about my site, the redirect should be transparent.
The process I have described above is what both parties (site A and site B) mandate.
Send back a document that contains the from with hidden input and include an onload handler that posts the form immediately to the other site. Using jquery's document.ready() solves the issue of whether the DOM is loaded before the post occurs, though there are other ways to do this without jquery. You might want to include some small message on the screen to the effect that the user will be redirected shortly and provide a link which also does the post
...headers left out...
<script type='text/javascript'>
$(document).ready( function() {
$('form:first').submit();
});
</script>
<body>
<form action='othersiteurl' method='POST'>
<input type='hidden' value='your-encrypted-xml" />
</form>
</body>
You are thinking about this too process oriented, it would take you a month of sundays to try and work out all the bugs and moving parts with what you suggest.
You are already doing a post to another server so you really don't need to do anything. The form you have is already perfect, and when the other server intercepts the request that is when it makes the decision to either allow to user in and continue in through the site, or redirect them back to their Referer (sic) in the header. When redirecting back to the Referer they may want to tack on a message that says what was wrong, such as ?error=no_auth
I wrote on this for another question a while back. Hope this helps:
How do you pass an authenticaticated session between app domains