I am working on a system which displays the live status/stages of the system creation.
Example -: If I fill a hosting form then on my form it should display the status of the system. Like domain created, files hosted , etc in a progress bar. I want to achieve this without using data base.
Note: All the operations will be performed on a different system and my hosting form is on a different system.
Hurdles: Multiple forms can be filled at the same time.
What I have tried.
Writing steps to database and read from there.
Do curl post to a specific function. But in that case I have to use DB.
I am looking for a way where there is no db interaction required and I can see the status dynamically after filling the form.
There is 1 solutions for this:
Send and receive information using AJAX from and to server wich has installed software with API
I think this is what you want to do.
Feel free to correct my understanding of the issue, but here's how I see this at the moment.
You have a web site that has multi stage forms. So user fills the first one, then sends it, and gets the next one to be filled.
You also have a web server, probably running PHP, that handles user interaction. So whenever user fills a form, your server application proceeds with that and gives the user the next one.
Furthermore, there are multiple external servers and services that your PHP application gives orders to based on the information given by the user.
You will want to show process information from external services whenever things do proceed.
Finally, you don't want to use a oh so heavy database solution if a lighter one exists.
If I have gotten the facts about right so far, there may be a suitable solution to help you out.
To begin with, it's worth mentioning that PHP has its own session mechanism. Its data storage defaults to flat files, which may or may not be suitable for your use. Yet it requires almost no configuration or setup and offers a persistent storage, so it's by far the easiest option, in my opinion.
Note, that if the amount of information to be stored is very small, you can bypass the application data storage altogether and stick to the cookies. Read on form submit, update during the PHP process and send update the cookie accordingly as part of the response. You can encrypt the data in order to make it harder to alter by the user.
Lastly, there's this option called cache. There are multiple technologies for this when working on PHP. For instance: xcache and APC. These store information in RAM, which obviously has its downsize, since data can basically vanish at any given time - you can control this, though.
No matter the choice of data storage, the general idea is as follows:
When user first interacts with your service, create a session identifier and an approriate cookie to identify the user later on.
When user has filled the first form and sends it, read the information and either store it in the cache or in the cookie. When storing and reading information from and to the cache, either prefix or namespace it using the session identifier used by user. This way there can be multiple users using the service at any given time! When done, send the second form to be filled.
When user eventually sends the second form, read from the cache or from the cookie the information given to the first one. Now, should the information be missing, there has been an error in the filling process (or cache has been invalidated due to long time period or cookie expiration time - you will want to take these things into account, too).
So long things are going nicely, build up your information gathered from the forms. Whenever you have enough information to do so, make a request to the external service to really make things happen.
Now, lastly. You can do periodical ajax requests from the client. Therefore you get not only the forms sent, but also occasional "how is the process going?" queries. Now, whenever you receive a request like that from the browser, you can identify the user by session identifier and make a call from your PHP application to your external service, asking for a status of any kind. You then simply forward the information to the browser that has been waiting the answer all this time.
Note that you may have to store service spesific information in your cache to do this.
This setup, however, effectively gives you the ability to control data flow in your PHP application without revealing the services behind it. It's also lightweight enough to develop as it requires no additional external software for short term data storage.
Related
There is any way to check the login status through different programming language?
Right now I'm using three session (same name) that starts at the same time after the login process, using ajax.
Right now, the login.html form is processed on three files: login.aspx, login.asp and login.php but it's seems too slow and weird. I'm combining three different services from the same company into one, after re-building the users and others common tables in mysql, everything seems to work fine, but I'm really scared about security bugs.
Just to let you you know, I have to check the login session status before any ajax callback, so if the user is working on an ASP page calling PHP through Ajax, may be that the session is still active on the ASP, but expired on the php file.
Any valid method to check all in one time? I can also accept a cookie solution but how to make it readable between php, asp and .net?
This sounds like single sign-on to me. Let's try to split the problem.
There is any way to check the login status through different programming language?
You're not really interested in the language used. Any language, given the same info and algorithm, would decode with success the same encrypted data. I guess you're instead having problems because PHP's application logic regarding this point is different from the ASP's one.
So for the first point, you can
Implement / normalize the same session checking logic among all of your apps. This is probably unfeasible, because you might be using Laravel here, and ASP.Net on the other, and the two are probably slightly different in this regard. If you can, do this, or...
Look into JSON Web Tokens. I won't go into detail, but these were more or less designed to solve this class of problems. They are also easy to handle, but be aware, there are aspects you have to take care of when using them for user authentication.
[...] Just to let you you know, I have to check the login session status before any ajax callback, so if the user is working on an ASP page calling PHP through Ajax, may be that the session is still active on the ASP, but expired on the php file.
Not to be that guy, but some concepts are somewhat deformed here. Sessions don't expire on files; they normally are setup with a given expiration time and a given domain. So generally speaking, a session opened from a PHP app, and stored on a cookie, then read from an ASP one shouldn't change, given that no difference exists between the two app's session handling logic.
Any valid method to check all in one time? I can also accept a cookie solution but how to make it readable between php, asp and .net?
For both of the solutions i suggested above is, especially for the cookie one, it's important you make the apps absolutely identical in respect to session handling. While this is trivial with JWT (as there's barely any logic on the app's side), this may prove to be harder with cookies if the authentication logic comes from some one else's code (as in a framework).
I haven't asked about single sign-out, and at this point i'm afraid to ask :). But these are some guidelines:
If going the cookie route, be aware of cookie's domain. A cookie is normally valid for every request coming from the website domain (name.com), but you may have some of your apps under a subdomain (like, phpapp.name.com). In this case, be sure the cookie created from the given app is valid for the whole domain, and not just the subdomain. And make the apps available at subdomains / pages under the same domain. Cookies don't work cross-domain, and you have to deal with that, since cookie domain policy is enforced at browser level.
Launching three AJAX calls means triggering three login procedures. I suppose all of these would terminate, at some point in the future, and all of those would be storing / rewriting the cookie. If the apps understand the same cookie, it's mandatory you open the login process on just one of them. This would store the cookie, which would then be automatically picked app from, say, a page in the second app, giving you a seamless transition into a logged-state in the second app.
JWT would normally require some JS work, which you may like since the same script can easily be loaded in all of your apps. On the other side, you can be sure that different server libraries handling JWT would all work the same for you, thus ensuring compatibility.
Personally, i would look into JSON Web Tokens.
You can develop your own session provider which stores data in a separate place (for ex. in database or files). Then everything you need to do is write some code in every environment to handle your session information from that provider. Because you use only one source to store session information there will be no problem with synchronization between any of yours environment.
If you need then you can use a webservice for exchange session information between every environment and session provider. Every application can use security connection to get and set information about session from that session webservice.
I think you can do this!You can create provider which stores data into database. Then Write some cool code to manage your provider.You can also use webapp or sevice.Every service use security to get and put information.
I have an html based application that allows users to store and search information in a mysql database. They run this on their own servers, so it isn't centralized. I'd like to add a function that allows them to see if their information corresponds to any known info in a central database, and if it isn't, they would have the option to add it to the central db. I'm not sure if the triggering script would be best placed on the client, or server side, so I'm at a loss as to where to start with this. Any script or config suggestions would be welcome.
Edit to add:
The data is preformatted, not created by the user. It consists of 7-10 fields of data that will likely be consistent with that seen by other users. The purpose is to build a troubleshooting database for users to reference or add to. The central server will be based on Q2A to allow upvotes, comments, etc.
This seems like the opposite of what Freebase does. In Freebase, users can connect to the Freebase API and check to see if something exists in the Freebase API if it does not already exist in their database. It is then up to them to cache the entry for faster retrieval in the future. Alternatively, at least in the past, the Freebase community enabled writing to the Freebase database using the MQL API.
If you are suggesting would strike me as being very involved. If you have content creators you really trust, you maybe can get away with not having any review process, but otherwise you will need some peer review and perhaps some programming. Unless you have no content standards, and it is anything goes, your database could quickly become overloaded with nonsense or things you don't want your website to be associated with (whatever those somethings might be).
Without knowing more about your database, I can't really say what those things would be, but what I will say is that if you are looking to have people throw stuff into a centralized location, you may want to (a) use something like OAuth, (b) set up some balances, because while one of your clients may think it's very important to have the 100 reasons why liberals/conservatives suck", another one of your clients may take offense. Guess who they will blame?
That being said, creating a RESTful API (don't know if you already have one or not) with a flag for insert_if_not_exists could work.
i.e. api.php?{json_string} would be picked up by a function/functions which determined what the user wanted to do in the json_string.
On the backend, your PHP function could parse it to an array very easily and if the insert_if_not_exists flag is triggered, you can create the post while you pull the data. Otherwise you just pull the data (or leave that part out if you only want to give them the option to post and not to pull in this fashion).
I'm considering building a security service in PHP that would hold user credential information , the most important of them would be tokens of logged in users. This service would be accessed by some kind of an API (REST, SOAP, whatever) by another API (an external user connects through a website API which checks credentials in another API - the one we're considering now).
There is a possibility to store tokens (and other information) in RDBMS. But this solution doesn't seem clean to me (tokens will remain in the database even if they're already expired, I would have to implement a mechanism for clearing expired sessions, etc). I was thinking about using native PHP session management ($_SESSION). Is that possible? Does anyone have experience with doing such things?
I thought of following problems:
when a PHP-based website is deployed on www server, users access the URL via browser and their native sessions are created using browser cookies. If there was one webpage API that would connect to security API, would there be only one session object all the time? Is it configurable?
How precisely sessions are created and how can I affect the mechanism (e.g. not to base it on cookies)?
My advice would be to use a database.
Let me start out with explaining the general concept of sessions. Sessions can be seen as server-side cookies. The location of the $_SESSION variable storage is determined by PHP's session.save_path configuration. Usually this is /tmp on a Linux/Unix system. Sessions have a session-parameter of the client associated with them. When a session_start or something like that is issued, the server will retrieve the file/session based on the session-parameter provided by client. As these are just stored files, it is possible for the server to read the sessions of other clients.
That brings me to the second problem you describe. If I am correct you want to have some api request information about a session of some user. Based on the first paragraph, you hopefully understand that the purpose of sessions isn't to use it as some sort of global storage. Of course it is possible. You could have the foreign APIs include the session-parameter or you could read the session-files manually, but to me these seem dirty fixes. It just isn't what sessions are build for.
The only other thing which attracts you to using sessions is the automatic timeout of sessions. However this simple logic you could easily implement when using a database. What you should do is register the time of the last activity of the user in your database. When an API requests the data of a user you can simply check whether the current time - the last active time is lower than a certain threshold. If that is not the case, the session expired and, at the same time, you can drop the session from the table. This is the more or less the same general method as sessions internally use, which requires no regular cronjobs (although they still could be useful to cleanup the database) to remove sessions.
So don't be afraid to use a database to store data, after all they are build (and optimized) to do that exact thing.
I have been playing around with Node.js for two days now, I am slowly understanding how it works. I have checked multiple threads and posts now but I seem to either misunderstanding them or the way I am thinking about this application is completely wrong.
My application is mainly based on PHP and uses Node.js as a notifications system.
I first wanted to this solely in Node.js but I am more familiar with PHP so that is why I only want to use Node.js as a notifications system.
I do not have any real code to show as I have been mainly playing around and see all what Node can do and so far it seems to be the thing I need, there is one thing I just can't figure out or seem to mis understand. So far I figured out how to send data between the user and the server and used socket.io for this.
So, what if I have a user, which is registered and logs-in on my application. He then has a socket id from socket.io, but when the user leaves my application and comes back the next day his socket ID is changed because it seems to change on every connection. I need to have my users somehow always have the same socket ID or something else which tells my node.js server that it should only send data to one specific user or multiple users. Also, as the socketid seems to change on every request it is even changed when the user visits a different page so I don't ever seem to know which user is what.
I am a little confused and the flow of working with both PHP and Node.js is still a little mystery to me so I hope my question is clear. I dont want to be depending on many modules as I find all these different modules kind of confusing for a beginner like me.
As long as PHP-Node.js are using sessions stored somewhere else other than flag file sessions let's say a cache service or a database mysql or nosql ..
you can use the "same flat file" sessions thought cache or database could be make your application "more"of course there are additional practises of allowing authenticated users to try to connect by controlling when to render the javascript code that holds the information to connect to socket.io server, where an additional list is stored in memory of all connected having information like username/log/timestamps/session variables/etc..
I tried implementing a code where I want only those users to register whose email I have stored in one database so that the people of only that particular place can register into the database. So I wanted that during the registeration to the website when user enter the email my scripts checks one database to see if that user can register there and then if yes, check the second database to see if the user has already registered or not then. If not then only register the user.
PHP is serverside, so your includes dont have anything to do with the browser cache. Your client connects to your sever, PHP does its processing and then returns the result.
An include just finds the file on the servers disk and executes it. If anything it will be a little slower, however its very unlikely this is a large performance bottleneck. You definitely want to keep your files nice and short, and use includes logically.
If you are optimising its important to identify what is slowing you down first.